Closed
Bug 1300800
Opened 8 years ago
Closed 8 years ago
Cu.getObjectPrincipal() doesn't work as expected on a sandbox object
Categories
(Core :: XPConnect, defect, P2)
Core
XPConnect
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: ehsan.akhgari, Unassigned)
References
Details
STR:
1. Update to 1e7eb0625d3e and build.
2. Switch <https://hg.mozilla.org/integration/mozilla-inbound/rev/1e7eb0625d3e#l8.20> and <https://hg.mozilla.org/integration/mozilla-inbound/rev/1e7eb0625d3e#l8.36> to call Cu.getObjectPrincipal().
getObjectPrincipal() gets the principal off of the compartment, but getSandboxPrincipal() in the patch gets it off the SandboxPrivate object, and for some reason they seem to be different. I have not investigated why.
(Follow-up from bug 1297687.)
Comment 1•8 years ago
|
||
I'm in meetings all week and then on PTO. Gabor, do you have a minute to repro the steps and see if there's anything crazy going on we should be worried about?
Flags: needinfo?(gkrizsanits)
Comment 2•8 years ago
|
||
(In reply to Bobby Holley (:bholley) (busy with Stylo) from comment #1)
> I'm in meetings all week and then on PTO. Gabor, do you have a minute to
> repro the steps and see if there's anything crazy going on we should be
> worried about?
Sure, I'll do this today.
Flags: needinfo?(gkrizsanits)
Comment 3•8 years ago
|
||
By the way, at first glance I think the patch has a bug. For IPC we must take care of serializing this extra bit of added info to nsEPs, no?
http://searchfox.org/mozilla-central/source/caps/nsJSPrincipals.cpp#261
Comment 4•8 years ago
|
||
(In reply to :Ehsan Akhgari from comment #0)
> STR:
>
> 1. Update to 1e7eb0625d3e and build.
> 2. Switch
> <https://hg.mozilla.org/integration/mozilla-inbound/rev/1e7eb0625d3e#l8.20>
> and
> <https://hg.mozilla.org/integration/mozilla-inbound/rev/1e7eb0625d3e#l8.36>
> to call Cu.getObjectPrincipal().
>
> getObjectPrincipal() gets the principal off of the compartment, but
> getSandboxPrincipal() in the patch gets it off the SandboxPrivate object,
> and for some reason they seem to be different. I have not investigated why.
>
> (Follow-up from bug 1297687.)
Sorry but I could not reproduce this. The tests pass with both Cu.getObjectPrincipal and
getSandboxPrincipal. I've added an 'is' check to compare the two principals they return and
that returns true as well, so they seem to return the same object. Are you sure you didn't
have any other modification in your copy of 1e7eb0625d3e ?
Flags: needinfo?(ehsan)
Reporter | ||
Comment 5•8 years ago
|
||
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #3)
> By the way, at first glance I think the patch has a bug. For IPC we must
> take care of serializing this extra bit of added info to nsEPs, no?
>
> http://searchfox.org/mozilla-central/source/caps/nsJSPrincipals.cpp#261
Yeah looks like you're right! But it's OK, the patch has been backed out already.
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #4)
> (In reply to :Ehsan Akhgari from comment #0)
> > STR:
> >
> > 1. Update to 1e7eb0625d3e and build.
> > 2. Switch
> > <https://hg.mozilla.org/integration/mozilla-inbound/rev/1e7eb0625d3e#l8.20>
> > and
> > <https://hg.mozilla.org/integration/mozilla-inbound/rev/1e7eb0625d3e#l8.36>
> > to call Cu.getObjectPrincipal().
> >
> > getObjectPrincipal() gets the principal off of the compartment, but
> > getSandboxPrincipal() in the patch gets it off the SandboxPrivate object,
> > and for some reason they seem to be different. I have not investigated why.
> >
> > (Follow-up from bug 1297687.)
>
> Sorry but I could not reproduce this. The tests pass with both
> Cu.getObjectPrincipal and
> getSandboxPrincipal. I've added an 'is' check to compare the two principals
> they return and
> that returns true as well, so they seem to return the same object. Are you
> sure you didn't
> have any other modification in your copy of 1e7eb0625d3e ?
Yeah, quite certain. Did you test in both e10s and non-e10s mode? I don't remember where I saw the bug...
Flags: needinfo?(ehsan)
Comment 6•8 years ago
|
||
(In reply to :Ehsan Akhgari from comment #5)
> Yeah, quite certain. Did you test in both e10s and non-e10s mode? I don't
> remember where I saw the bug...
I just did, but I get the same result for non-e10s mode as well.
Reporter | ||
Comment 7•8 years ago
|
||
OK, I don't have anything more to add then, sorry! Unfortunately I'm dealing with a lot of more important things, so I won't have time to try to reproduce any time soon. (I have already purged the build from last Friday.)
Updated•8 years ago
|
Priority: -- → P2
Comment 8•8 years ago
|
||
Assuming Ehsan doesn't have concrete plans to try to reproduce this, I'm going to mark this WFM given gabor's attempt to reproduce and my general skepticism that this could ever happen.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•