326767 - Want a way to expose interfaces to chrome JS only (completely hidden from content)

Status: RESOLVED WORKSFORME

(Core :: XPConnect, defect)

Description

[Boris Zbarsky [:bzbarsky]]

I'd really like a way to expose interfaces on JSObjects to only chrome (or possibly UniversalXPConnect) JS.  Right now that's impossible due to interface flattening, basically.  But if we could do this, we could, for example, have a useful scriptable nsIPrincipal getter on DocumentChrome.  And a useful scriptable |readonly attribute nsIURI baseURIObject;| on NodeChrome.  And so forth.

Brendan says:

<brendan> bz: we could make xpconnect do something smart based on JS_IsSystemObject
<brendan> if we had a [system] dingus in xpidl

Which might work, what with XPCNativeWrapper.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Shaver suggested that something like the namespaces facility described at http://www.mozilla.org/scriptable/typelib_file.html#InterfaceDirectoryEntry_namespace might be a better fit for this.  He thinks the syntax for using it would involve the "module" keyword (sadly not present in http://www.mozilla.org/scriptable/xpidl/idl-authors-guide/keywords.html).

The idea then would be that we would have some way for "things" (JSContexts? Principals?  Something else?) to opt into seeing non-default namespaces.

Comment 2

[Brendan Eich [:brendan]]

(In reply to comment #1)
> Shaver suggested that something like the namespaces facility described at
> http://www.mozilla.org/scriptable/typelib_file.html#InterfaceDirectoryEntry_namespace
> might be a better fit for this.  He thinks the syntax for using it would
> involve the "module" keyword (sadly not present in
> http://www.mozilla.org/scriptable/xpidl/idl-authors-guide/keywords.html).
> 
> The idea then would be that we would have some way for "things" (JSContexts?
> Principals?  Something else?) to opt into seeing non-default namespaces.

I smell overengineering.

Sure, with JS2/ES4 namespaces we could probably make this work, along with work to implement XPIDL modules (vocabulary wars don't help).

But we aren't going to want to make this bug depend on all those things.  And we have the "system" flag already for script (via filename prefix) and object (via a single GC-thing flag, no extension to arbitrary namespace or module).  Worse is better says to build on this, quickly, and declare victory here.

/be

Comment 3

[Boris Zbarsky [:bzbarsky]]

The system flag for scripts and objects is not what we want here.

Further, no one's proposing we actually use JS2 namespaces.  I think the suggestion was to only interface-flatten the interfaces in question when the caller has explicitly opted into the namespace (whatever that means; I suggest checking that the UniversalXPConnect capability is enabled).

But if IDL namespaces will get mapped to JS2 namespaces in the future, then I guess we need a different solution here.

So all I'm aiming for is a way to flag interfaces as "don't flatten it by default" and a way for UniversalXPConnect code (at least) to get the flattening.  I don't care so much whether we use a "system" bit for that or whether we use a special namespace....  The namespace thing sounded better to shaver (and me) because namespace pollution is the real problem we're trying to solve; the "system" aspect of things is not really relevant.

Comment 4

[Brendan Eich [:brendan]]

Yes, my point about namespace was that it's a different thing in JS2 and in other programming languages from what this bug seems to want.  You could use namespaces that are access-controlled, or you could access-control names in a single flat namespace -- but the vital part seems to be the access control, not the name segregation or lack of it.

IOW, with namespaces, even if one is not implicitly open (allowing unqualified reference to names in it), you can use a longer form of naming (ns::id in JS2) to get at the named thing.

Another way to ask this: do you want to prevent flattening, or actually preclude access? Even without flattening, won't there be a way to QI to the hidden part.

/be

Comment 5

[Boris Zbarsky [:bzbarsky]]

> but the vital part seems to be the access control, not the name segregation or
> lack of it.

Actually, the name separation is the vital part.  Access control for the use cases we have here is provided by the inability of unprivileged script to create XPConnect wrappers for nsIURI, nsIPrincipal, etc.  And for cases where content _could_ call the method, I think we should use the existing access control mechanisms (CAPS, nsISecurityCheckedComponent, whatever).  The problem we're trying to solve is namespace pollution of the DOM namespace with our internal properties (due to interface flattening).  Otherwise, access to those properties on the part of a web page (eg if it's enumerating all props, or trying to set expandos, or whatever) will throw, which is not desirable.

> you can use a longer form of naming (ns::id in JS2) to get at the named thing.

And if you're unprivileged content you'll get an exception when you do.  But since you undertook the effort to do it (using namespaces explicitly, etc), that's ok.

> Another way to ask this: do you want to prevent flattening, or actually
> preclude access?

The former.

> Even without flattening, won't there be a way to QI to the hidden part.

Possibly, yes.  That's ok by me, per above.

Comment 6

[Brendan Eich [:brendan]]

Duh, then namespaces are exactly what you want!

/me smacks self in head.

We can make this work.  Shaver, what's a good ref for the OMG IDL module or namespace fu?

/be

Comment 7

[Boris Zbarsky [:bzbarsky]]

So do we think we can make this work early enough in 1.9 that we could fix bug 324464 and the security followups it blocks?  Or should we work on an alternate (uglier?) solution for bug 324464?

Comment 8

[jhp (no longer active)]

I am also looking at using namespaces for interfaces, primarily for use in Java (bug 330256).

The OMG IDL spec defines the "module" keyword for this purpose, which corresponds to the C++ "namespace" and the Java "package" keywords.

In IDL, "module" encapsulates the "interface" (that is, "module M { interface I {...} }").  We could do the same for XPIDL to keep parity with IDL, and store the name in typelib's "namespace" record.  Or perhaps just add it to the interface header, after the "uuid" declaration.

I think my needs for bug 330256 may be more involved than what is called for here.  Ideally, all interfaces should have an associated namespace, but for backwards compatibility, interfaces that don't designate a namespace would get the default ("org.mozilla.xpcom" in Java, but that may change; see bug).

Comment 9

[Andrew McCreight [:mccr8]]

I think this exists in WebIDL now, with [ChromeOnly].