Last Comment Bug 681648 - Sandboxes with the same URI string end up having different Principals
: Sandboxes with the same URI string end up having different Principals
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: unspecified
: x86 Windows 7
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-24 08:04 PDT by Gabor Krizsanits [:krizsa :gabor]
Modified: 2011-08-25 02:43 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Gabor Krizsanits [:krizsa :gabor] 2011-08-24 08:04:56 PDT
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.
Comment 1 Kyle Huey [:khuey] (khuey@mozilla.com) 2011-08-24 08:46:25 PDT
Can somebody point me to the implementation of the "module" protocol?
Comment 2 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-08-24 09:02:31 PDT
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?
Comment 3 Kyle Huey [:khuey] (khuey@mozilla.com) 2011-08-24 09:04:23 PDT
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.
Comment 4 Gabor Krizsanits [:krizsa :gabor] 2011-08-24 09:47:11 PDT
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?
Comment 5 Boris Zbarsky [:bz] 2011-08-24 11:43:46 PDT
We could just introduce a way for nsSimpleURIs to compare based on URI string equality if we want to (via a protocol flag).
Comment 6 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-08-24 12:14:31 PDT
Since the Sandbox constructor takes a principal, why not just pass one explicitly, instead of using URIs which don't mean much?
Comment 7 Gabor Krizsanits [:krizsa :gabor] 2011-08-24 12:38:16 PDT
(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.
Comment 8 Boris Zbarsky [:bz] 2011-08-24 12:44:17 PDT
> 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).
Comment 9 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-08-24 12:46:51 PDT
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?
Comment 10 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-08-24 12:47:12 PDT
I guess I mean "createNullPrincipal", since it would be unique each time, not a singleton.
Comment 11 Kyle Huey [:khuey] (khuey@mozilla.com) 2011-08-24 12:47:25 PDT
Why can't you just create a null principal by contractID?
Comment 12 Gabor Krizsanits [:krizsa :gabor] 2011-08-24 12:52:02 PDT
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.
Comment 13 Boris Zbarsky [:bz] 2011-08-24 13:11:41 PDT
I've fixed those docs.
Comment 14 Gabor Krizsanits [:krizsa :gabor] 2011-08-25 02:43:13 PDT
I close this issue for now since the real problem is solved.

Note You need to log in before you can comment on or make changes to this bug.