+cc Diego, who has experimented with packaging Firefox on Steam...
Thanks Alex,
It sounds as though we can work around all of these issues, based on your
feedback. I believe that we could proxy any file access needed by the content
process. The main process will need to access some resources in these builds
that are not normally accessed by the normal Firefox builds for the Steam
integration. Perhaps opening these resources isn’t too much concern for the
regular Firefox builds. If not, we could perhaps select these alternate
sandboxing rules with a command-line parameter?
We have also explored treating this “Steam VR Browser” as a separate product,
and using compile-time flags to select the desired code to build and assets.
We could still hard-code the rules, but skip them at build time for regular
Firefox builds. In this case, we are effectively forking the “browser”
directory into a “vrbrowser” and stripping it down to just what we need.
We liked the re-pack option (ie. Similar to QBRT), as we don’t have to put as
much load on our test infrastructure; however, this is still an option on the
table if a dedicated build and the associated costs is justified.
Cheers,
- Kearwood “Kip” Gilbert
From: Alex Gaynor
Sent: May 9, 2017 7:58 AM
To: Kearwood Kip Gilbert
Cc: dev-platform@lists.mozilla.org
Subject: Re: Running mochitest on packaged builds with the sandbox
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
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
