Sandboxes with the same URI string end up having different Principals

RESOLVED FIXED

Status

()

Core
XPConnect
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: krizsa, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
Creating two sandboxes with "module:foo" as URI, the sandboxes will end up having different principals. For addons we need to find an URI scheme that works in such a way that the principals generated from the same URI strings are equal.
Can somebody point me to the implementation of the "module" protocol?
Could you be more specific about what you're trying to achieve? Since sandboxes don't have any privileges by default, are you just asking that you create two sandboxes that can be given access to each other? If so, could we just have two scopes in the same "sandbox"? Is it important that the sandboxes be in the same or different compartments?
We talked through this a bit on IRC.  AIUI, he wants to create sandboxes that use the same JSCompartment.  Currently we assign them different JSCompartments because their principals do not compare equal.  This is because the 'module' uri scheme that's being used here uses nsSimpleURI, and nsSimpleURI's never compare equal in NS_SecurityCompareURI unless they are the same C++ object.
(Reporter)

Comment 4

6 years ago
Exactly as Kyle said. Also here is the original Bug 677294 this one is related to. And originally the issue came up here Bug 636145 (see last comment 22 from Alex). Currently each sandbox gets into a different compartment, but I want to change that (see my patch for the first bug I mentioned) since addons used way too many compartments because of its modules which leaded to memory problems. Having two scopes in the same sandbox sounds like a different approach than the one I chose, where as, sandboxes sharing the same compartment. Actually I think that sounds like an interesting alternative, is there a way to do that?
We could just introduce a way for nsSimpleURIs to compare based on URI string equality if we want to (via a protocol flag).
Since the Sandbox constructor takes a principal, why not just pass one explicitly, instead of using URIs which don't mean much?
(Reporter)

Comment 7

6 years ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #6)
> Since the Sandbox constructor takes a principal, why not just pass one
> explicitly, instead of using URIs which don't mean much?

That's exactly the workaround I suggested, the only thing that is a bit annoying that it means that you have to create a dom window object to fetch a principal from it, since there is no other way to create a principal from js. That should be done for each module. So it could work but I thought if there is an easy fix for it I'll do it, if not at least I get a better understanding of this area. 

(In reply to Boris Zbarsky (:bz) from comment #5)
> We could just introduce a way for nsSimpleURIs to compare based on URI string 
> equality if we want to (via a protocol flag).

I'll check it with the jetpack team if it's important for them or they can live with the workaround mentioned by Benjamin and then see if I can implement it.
> since there is no other way to create a principal from js.

nsIScriptSecurityManager.getCodebasePrincipal works just fine from JS in anything resembling a recent Gecko (something like 1.9 or later).
Could we add a method "getNullPrincipal" to nsIScriptSecurityManager so that this code could create null principals to pass for identical sandboxes? Or is that not something that SSM can support?
I guess I mean "createNullPrincipal", since it would be unique each time, not a singleton.
Why can't you just create a null principal by contractID?
(Reporter)

Comment 12

6 years ago
Right... I think I ran into some outdated docs again (https://developer.mozilla.org/en/Security_check_basics). And yes, null principals should be easy to create by contractID. Thanks for the help.
I've fixed those docs.
(Reporter)

Comment 14

6 years ago
I close this issue for now since the real problem is solved.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.