Closed Bug 523896 Opened 15 years ago Closed 15 years ago

Implement "UniversalXPConnect" replacement extension.

Categories

(Core :: Security: CAPS, defect)

Product:
Core
Component:
Security: CAPS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 549539

People

(Reporter: jst, Assigned: sicking)

Details

As discussed in the newsgroups etc, we're on a path (even if it's been a slow one so far) to eliminate the API we have that lets users (if they've set a pref to allow it) request privileges (netscape.security.PrivilegeManager.enablePrivilege("...");). Most commonly the privilege requested is "UniversalXPConnect", which hands you the key to the computer, and so on. This is something that's primarily used in our testing infrastructure, in mochitest in particular, and will somewhere down the road be replaced with something else and this feature will be completely unavailable to the web.

The "something else" there should per discussions between mrbkap, dveditz, myself, and others, be an extension that exposes a function to JS that lets JS evaluate script with full system principals. It would be an extension that we'd make sure is in the blocklist for release build, and one that could be pretty rigorous about checking that it is only ever being used in our testing framework, would require a non-default pref to be set, etc, so that it's not something that leaks out to users and does harm there.

Blake said he'd take a stab at writing this as the first step in eliminating enablePrivilege(). Other ideas and thoughts are of course welcome as well. Nothing's set in stone here yet, except for the desire to eliminate enablePrivilege().
So I can see two possible paths here. Blake talked about crating something like a "reversed SafeJSObjectWrapper" which would execute arbitrary javascript with the system principal.

Alternatively, we could simply create a object that exposes the capabilities we need in our tests. So something like

interface nsIScaryTestSupportObject : nsISupports
{
  void setBoolPref(DOMString aPref, boolean aValue);
  void setStringPref(DOMString aPref, DOMString aValue);

  nsIFile createTemporaryFile(DOMString aName, DOMString aContent);

  void markEventTrusted(nsIDOMEvent);

  ...
}

I can't really say which is better. The above seems easier to implement, but the number of functions can grow unbounded.
That approach doesn't seem as extensible to migrating existing intranet stuff that uses enablePrivilege, right?
I thought our plan for intranet was to tell them to use extensions? And possibly add an API that allowed extensions to more easily expose functionality to webpages in a safe way. Such as have an API that allows an extension to say "expose these here objects to webpages from domains X and Y".
Yes, that is in fact our plan.  I see no reason for us to not proof-of-concept it ourselves with mochitest; do you?  Eating our own dog food and all...
Agreed.

I guess i don't understand what you're referring to by "That" in comment 2
"That" == "create a object that exposes the capabilities we need in our tests"
Or more precisely, since that _is_ in fact what we want these intranet extensions to be doing to some extent, "that" == "create such an object that we'd not be willing to ship in firefox modulo some simple per-site configuration" or something...

Maybe I just shouldn't worry about the intranet case, but it feels like as long as we're solving this problem we shouldn't solve it twice over.
So, I'd like to be clear here: I was concerned that every time I brought this topic up, I'd hear things like "Oh, yeah, we're going to write an extension and UniverslXPConnect will die; oh, by the way, here's a pony."

I'm going to write this extension as a straw-man so that people (hopefully) start thinking about what the best way to implement the extension is. I'm assuming that "chrome eval" is not what's really wanted. For one thing, passing objects *into* the evaluated code is going to be awkward. For another, it's a bit like overkill: all we need to do is grant full access to one object (or maybe an object graph), we probably don't need to allow arbitrary code execution.
Blocks: 546848
From my perspective, replacing the use of UniversalXPConnect in mochitests will probably only require a limited set of things. mrbkap is right in that eval'ing strings would probably be a clumsy way to do things. Implementing everything we need as individual methods on one XPCOM component would work, but certainly has the possibility to grow exponentially (and we'll wind up with methods that are only needed by one test being exposed globally).

I like the idea of being able to "bless" an object to grant it privs. An alternate proposal would be something like:
callWithPrivileges(thisObject, method, args)
which would be equivalent to running this.method(args), but with full access. I think either of those would be flexible enough that mochitest could accomplish everything it needed (including one-offs in individual tests).

Also, enabling it in an extension, with prefs etc, is fine. The test harness can take care of all of that.

CCing jgriffin because he's been looking into this in bug 533306.
For mochitests, the path I've taken in 533306 is to split individual tests up into "chrome" and "content" parts.  The parts that used to call UniveralXPConnect are moved to the "chrome" part, with a chrome:// url, which has all the privileges it needs.  The rest stays in the "content" part.  Both parts set up event listeners for custom messages, and either part can invoke a method in the other part (with optional callbacks) by way of these custom messages.  The messeage handling is all done by some helper routines.

There are some limitations to this approach, namely, you can't pass some objects (like window or document objects, or anonymous functions) between "chrome" and "content" parts.  And this implementation does use eval.  So an extension that provides similar functionality without these drawbacks might be better.
Assignee: mrbkap → jonas
sicking: did you want to just dupe this over to bug 549539, or does this bug encompass more than what you intend to do there?
This bug is sort of all over the place, so I'm not really sure what to do with it :).
Ok, then let's not confuse the issue.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
No longer blocks: 462483, 546848
You need to log in before you can comment on or make changes to this bug.