Loosely based on Chromium git commit 86c3d9ef4fdf, but redone to insert a
sched_yield(), because treating EMSGSIZE as if it were EAGAIN/EWOULDBLOCK
is (as the Chromium developers note) likely to act as a busy-wait for the
receiver to make progress.
This needs more unit tests for the various pieces of what's going on
here (LinuxCapabilities, SandboxChroot, UnshareUserNamespace()) but
that's nontrivial due to needing a single-threaded process -- and
currently they can't be run on Mozilla's CI anyway due to needing user
namespaces, and local testing can just try using GMP and manually
inspecting the child process. So that will be a followup.
Using the equivalent of release assertions in the patch after this one
is easier to justify if I can't come up with vaguely legitimate reasons
why they might fail; this detects the ones I thought of.
This means that B2G plugin-container must (dynamically) link against
libmozsandbox in order to call into it before initializing Binder.
(Desktop Linux plugin-container already contains the sandbox code.)
Normally a document would size itself to the size of it's "container". If the document is a subdocument it will use the size of the iframe. If it's a root document it will use the size of the widget it is in. Overriding the viewport breaks this link, the document is now sized to whatever size the last call to nsIDOMWindowUtils::SetCSSViewport had. Of course this would produce a weird display on screen so we use this in conjunction with setting a resolution on the document. This means that the layout viewport (the size of the root frame and also approximately mScrollPort) is different from the visual viewport (what's visible on screen). The visual viewport is the composition bounds.
Boris and I debugged this. It looks like we're somehow ending up with an
XrayWaiver on the other end of a CrossOriginXrayWrapper. The specifics of how
this happens are a bit fuzzy to me, but it's presumably happening in all the
brain transplant weirdness we do when recomputing wrappers during document.domain.
Having an XrayWaiver there isn't unsafe - the wrapper computation algorithm
will ignore the waiver if the principals don't allow the caller to waive. But
it does throw a wrench in some brittle code that only expects certain kinds
of wrappers. Let's just do what XrayTraits::getTargetObject does. I don't think
this is really unsafe at all, because the only wrapper with a security boundary
is the CCW, and we're already stripping that off unconditionally with
Wrapper::wrappedObject.
Doug Turner
Jed Davis
Ryan VanderMeulen
Mats Palmgren
Jeff Muizelaar
Eric Faust
Geoff Brown
Blake Kaplan
Alexandru Tifrea
Wes Kocher
Timothy Nikkel
Andrew Halberstadt
Mason Chang
Daniel Holbert
Terrence Cole
Tooru Fujisawa
Landry Breuil
David Major
Ehsan Akhgari
Blake Wu
Jim Mathies
Andrea Marchesini
Makoto Kato
Fernando Jimenez
Bobby Holley