Change the way we do cross-compartment wrapper for Window and Location
Categories
(Core :: DOM: Core & HTML, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
People
(Reporter: bzbarsky, Assigned: bzbarsky)
References
(Regressed 1 open bug)
Details
Attachments
(2 files)
Once bug 1363208 is fixed, we will no longer need to use filtering Xrays for cross-origin Window and Location. We'll still want Xrays there for the chrome-to-content or extension-to-content cases, but for the normal web-exposed case we'll want a special CCW that has the following properties: 1) Is fully transparent (like a normal transparent CCW). 2) Does not enter the compartment of the target proxy (like Xrays). We will need to ensure that Window and Location proxy handlers can handle being called in a compartment different from the WindowProxy/Location compartment.
Assignee | ||
Comment 1•6 years ago
|
||
Once this is done, the incumbent global usage from bug 1363208 can be removed in favor of the current global, because of point 2 above.
Comment 2•6 years ago
|
||
So CrossCompartmentWrapper inherits from Wrapper and Wrapper inherits from ForwardingProxyHandler... I think it should be possible to add OurNewWrapper that also inherits from Wrapper but just uses the default traps provided by ForwardingProxyHandler? Another thought: maybe OurNewWrapper could assert it only wraps wrappers/proxies (it seems that will be true for Location and Window) and then it could just forward each trap directly to the target proxy's handler. I don't know if that makes sense, but I'm happy to help out with wrapper stuff on the JS side if needed.
Comment 3•6 years ago
|
||
(In reply to Jan de Mooij [:jandem] from comment #2) > I think it should be possible to add OurNewWrapper that also inherits from > Wrapper but just uses the default traps provided by ForwardingProxyHandler? Er, OurNewWrapper would have to inherit from *CrossCompartmentWrapper*.
Updated•6 years ago
|
Assignee | ||
Comment 4•6 years ago
|
||
Assignee | ||
Comment 5•6 years ago
|
||
The end result we want is that on the web cross-compartment wrappers for
WindowProxy and Location are always CrossOriginObjectWrapper. That needs to be true
for both cases that are different-origin (as now) and cases that are
same-origin, since they might become different-origin due to document.domain
changes but we don't want that to affect the wrappers involved.
On the web, all security checks are symmetric, so in WrapperFactory::Rewrap we
would have originSubsumesTarget == targetSubsumesOrigin in all web cases.
I claim that
originSubsumesTarget == targetSubsumesOrigin &&
(!targetSubsumesOrigin ||
(!originCompartmentPrivate->wantXrays &&
!targetCompartmentPrivate->wantXrays)) &&
"object is a WindowProxy or Location"
is a necessary and sufficient condition for using CrossOriginObjectWrapper.
Comparing to our current code, if originSubsumesTarget and targetSubsumesOrigin
are both false, then for the WindowProxy and Location cases we currently end up
with the following arguments to SelectWrapper:
securityWrapper: true
xrayType: XrayForDOMObject
waiveXrays: false
So SelectWrapper ends up returning CrossOriginObjectWrapper, which the new
condition keeps doing.
If originSubsumesTarget and targetSubsumesOrigin are both true, then there are
two cases. If both compartments have wantXrays false (which is always the case
on the web), then we end up with the following arguments to SelectWrapper:
securityWrapper: false
xrayType: NotXray
waiveXrays: false
and SelectWrapper returns CrossCompartmentWrapper. We want to do
CrossOriginObjectWrapper instead, as explained above.
Finally, if originSubsumesTarget and targetSubsumesOrigin are both true but one
of the compartments has wantXrays set, then we get:
securityWrapper: false
xrayType: XrayForDOMObject
waiveXrays: might be true or false
and then SelectWrapper might return a WaiveXrayWrapper or a PermissiveXrayDOM.
In this case we do not want to start returning CrossOriginObjectWrapper, and
this is a non-web case anyway, since web compartments can't set wantXrays.
Pushed by bzbarsky@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2ff333373fe4 part 1. Fix IsPlatformObjectSameOrigin to do the right thing when we're doing first-party isolation but turning off its effects on scripted property access. r=bholley https://hg.mozilla.org/integration/autoland/rev/9658187a54fb part 2. Change the way we do cross-compartment wrappers for Window and Location so they don't ever need to be recomputed. r=bholley
Comment 7•6 years ago
|
||
Backed out 2 changesets (bug 1471496) for causing CycleCollectedJSRuntime.cpp perma failures
push that caused the backout: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=9658187a54fbd9e7c5bda51fb4e5a041a7af77be
backout: https://hg.mozilla.org/integration/autoland/rev/63348118ef1d564a659f793c0ec9afe5d7f1cc8b
Comment 8•6 years ago
|
||
Log from failure above:
Found black to gray edge to gray Shape 0x24a0462d6970
from black Object Proxy 0x24a046214080 (compartment 0x122010550) shape edge
from black Object Window 0x24a046224100 (compartment 0x122010550) object slot edge
from black ObjectGroup 0x24a0462afd30 group_global edge
from black Object Function 0x24a0462d1900 (compartment 0x122010550) group edge
from black Shape 0x24a0462c3078 setter edge
from gray Object Object 0x24a04624f280 (compartment 0x122010550) shape edge
from gray Object HTMLDocument 0x24a046236130 (compartment 0x122010550) Shadowing DOM proxy expando edge
from root Preserved wrapper
Source: object 24a046214080
global 24a046224100 [Window]
class 1104c5cd0 Proxy
lazy group
flags: maybe_has_interesting_symbol not_native
proto <dynamic>
Found black to gray edge to gray Shape 0x24a0462d6970
from black Object Proxy 0x24a046214080 (compartment 0x122010550) ProxyObject_shape edge
from black Object Window 0x24a046224100 (compartment 0x122010550) object slot edge
from black ObjectGroup 0x24a0462afd30 group_global edge
from black Object Function 0x24a0462d1900 (compartment 0x122010550) group edge
from black Shape 0x24a0462c3078 setter edge
from gray Object Object 0x24a04624f280 (compartment 0x122010550) shape edge
from gray Object HTMLDocument 0x24a046236130 (compartment 0x122010550) Shadowing DOM proxy expando edge
from root Preserved wrapper
Source: object 24a046214080
global 24a046224100 [Window]
class 1104c5cd0 Proxy
lazy group
flags: maybe_has_interesting_symbol not_native
proto <dynamic>
Assertion failure: js::CheckGrayMarkingState(mJSRuntime), at /builds/worker/workspace/build/src/xpcom/base/CycleCollectedJSRuntime.cpp:1119
Assignee | ||
Comment 9•6 years ago
|
||
Bug 1525346 tracks fixing that failure. Many thanks to jandem and jonco for figuring it out!
Comment 10•6 years ago
|
||
Pushed by bzbarsky@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/317151999412 part 1. Fix IsPlatformObjectSameOrigin to do the right thing when we're doing first-party isolation but turning off its effects on scripted property access. r=bholley https://hg.mozilla.org/integration/autoland/rev/00cdd5991ace part 2. Change the way we do cross-compartment wrappers for Window and Location so they don't ever need to be recomputed. r=bholley
Comment 11•6 years ago
|
||
Backed out as Boris requested on irc because bug 1525346 was also backed out for failures:
backout link: https://hg.mozilla.org/integration/autoland/rev/bc6e94302fbf528815a89e33d9fc2fce8d7f1edf
Comment 12•6 years ago
|
||
Pushed by bzbarsky@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/462cfc9e96dc part 1. Fix IsPlatformObjectSameOrigin to do the right thing when we're doing first-party isolation but turning off its effects on scripted property access. r=bholley https://hg.mozilla.org/integration/autoland/rev/4abfd3bb9934 part 2. Change the way we do cross-compartment wrappers for Window and Location so they don't ever need to be recomputed. r=bholley
Assignee | ||
Updated•6 years ago
|
Comment 13•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/462cfc9e96dc
https://hg.mozilla.org/mozilla-central/rev/4abfd3bb9934
Updated•6 years ago
|
Updated•6 years ago
|
Description
•