Hi,
Hmm, VR appears to be an interesting challenge.
To expand a bit more on why mochitest+sandboxing is a challenge for
packaged builds: The way mochitest is set up is that there's a
configuration file which points to JS files to be loaded for tests. These
are loaded by the content process. This works ok in non-packaged builds,
because in those builds we allow read access to the entire source directory
("topsrcdir"); in packaged builds, we don't have this whitelist -- we only
allow read access inside of the .app (to use the macOS lingo), so
essentially content is trying to open a random JS file, and is blocked.
With that context, disabling sandboxing might be one option, another is for
your repack to include the mochitest JS files inside the packaged build,
then everything can work ok. We don't want to do this for general packaged
builds because there's no reason for SuperPowers.js (for example) to be in
a shipped FF, but if you're doing a special pack for testing it might make
sense.
Does that make sense?
For your other question, about configuration of sandboxing rules. Right now
we have the ability to have multiple different sets of sandbox rules, for
example plugin processes and content processes have different sandbox
rules, and so will GPU processes soon. With that said, it sounds like what
you're talking about is really in the content process -- for that case,
you're really better off remoting access to these resources through the
parent process. This keeps us from expanding the attack surface in content
(which is most exposed to the dangerous web), right now we're doing all we
can to restrict this, so I wouldn't be excited about opening it back up :-)
Cheers,
Alex
On Mon, May 8, 2017 at 2:14 PM, Kearwood Kip Gilbert <kgilb...@mozilla.com>
wrote:
> Hi all,
>
>
>
> The VR team is working on a Steam packaged browser with a VR specific UI
> and richer VR experience. In order to prevent the overhead of having the
> VR specific assets included in every Firefox build while still running on
> tested executables, we will be doing a repack build.
>
>
>
> WebVR will still continue to be supported in the regular Firefox builds;
> API surface area is the same in normal desktop builds. Mochitests
> validating these API calls should be unaffected.
>
>
>
> We will need a means for testing the VR frontend and assets that are added
> with the re-pack. Ideally, we could use the existing test mechanisms,
> including mochitests.
>
>
>
> Perhaps we could disable the sandbox for these front-end tests?
>
>
>
> The Steam packaged builds will also need slightly expanded access to
> resources such as files, registry, and pipes required for communication
> with Steam.
>
>
>
> Are there any plans to make the sandboxing rules configurable at runtime?
>
>
>
> Cheers,
>
> - Kearwood “Kip” Gilbert
>
>
>
>
>
> *From: *Alex Gaynor <agay...@mozilla.com>
> *Sent: *May 8, 2017 10:26 AM
> *To: *dev-platform@lists.mozilla.org
> *Subject: *Running mochitest on packaged builds with the sandbox
>
>
>
> Hi dev-platform,
>
>
>
> Top-line question: Do you rely on being able to run mochitests from a
>
> packaged build (`--appname`)?
>
>
>
> Context:
>
>
>
> The sandboxing team has been hard at work making the content process
>
> sandbox as restrictive as possible. Our latest focus is removing file read
>
> permissions from content processes -- the sandbox's value is pretty limited
>
> if a compromised content process can ship all your files off by itself!
>
>
>
> One of the things we've discovered in the process of developing these
>
> patches is that they break running mochitest on packaged firefox builds
>
> (this is the `--appname` flag to mochitest)! `try` doesn't appear to use
>
> this, and none of us use it in our development workflows, but we wanted to
>
> check in with dev-platform and see if we were going to be breaking people's
>
> development flows! While these restrictions are not on by default yet, once
>
> they are you'd only be able to run tests on packaged builds by disabling
>
> the sandbox. If this is a fundamental part of lots of folks' workflows
>
> we'll dig into whether there's a way to keep this working.
>
>
>
> Happy Monday!
>
> Alex
>
> _______________________________________________
>
> dev-platform mailing list
>
> dev-platform@lists.mozilla.org
>
> https://lists.mozilla.org/listinfo/dev-platform
>
>
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
