Re: Running mochitest on packaged builds with the sandbox

[Alex Gaynor]

Hey Kip,

We should probably move this to a different thread

The parent process has full privileges, so it can read whatever it wants.
As long as we express the IPC in a way that the parent can enforce rules
about filesystem access, basically so the child process doesn't use the IPC
as a generic "I can access _all_ the files now", I don't see a problem with
remoting these access. This lets us avoid needing to maintain more
variations in sandbox rules.

Alex

On Tue, May 9, 2017 at 7:08 PM, Kearwood Kip Gilbert <kgilb...@mozilla.com>
wrote:

> +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 <agay...@mozilla.com>
> *Sent: *May 9, 2017 7:58 AM
> *To: *Kearwood Kip Gilbert <kgilb...@mozilla.com>
> *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 m

Re: Running mochitest on packaged builds with the sandbox

[Alex Gaynor]

After some follow up investigations, it turns out the MacOS tests also rely
on this, we just hadn't noticed due to a different bug :-(

Short version: Sorry for wasting your time, you can ignore this thread.

All the other feedback we've gotten about general sandbox debugging will
still be considered :-)

Cheers,
Alex

On Tue, May 9, 2017 at 2:25 PM, Gian-Carlo Pascutto  wrote:

> On 08-05-17 19:26, Alex Gaynor wrote:
> > Hi dev-platform,
> >
> > Top-line question: Do you rely on being able to run mochitests from a
> > packaged build (`--appname`)?
>
> It seems our Linux tests do, actually:
>
> https://treeherder.mozilla.org/logviewer.html#?job_id=97391302=try
>
> "test-linux32/opt-mochitest-e10s-1 tc-M-e10s(1)" launches
>
> /home/worker/workspace/build/tests/mochitest/runtests.py --total-chunks
> 10 --this-chunk 1
> --appname=/home/worker/workspace/build/application/firefox/firefox
> --utility-path=tests/bin --extra-profile-file=tests/bin/plugins
>
> Using --appname. As expected, this then fails because the sandbox didn't
> get the exception added and correctly blocks the reading of some test
> files that are in a random place:
>
> /home/worker/workspace/build/tests/mochitest/extensions/
> specialpowers/chrome/specialpowers/content/MozillaLogger.js
>
> We may need another solution here.
>
> --
> GCP
> ___
> 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

RE: Running mochitest on packaged builds with the sandbox

[Kearwood Kip Gilbert]

+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

Re: Running mochitest on packaged builds with the sandbox

[Gian-Carlo Pascutto]

On 08-05-17 19:26, Alex Gaynor wrote:
> Hi dev-platform,
> 
> Top-line question: Do you rely on being able to run mochitests from a
> packaged build (`--appname`)?

It seems our Linux tests do, actually:

https://treeherder.mozilla.org/logviewer.html#?job_id=97391302=try

"test-linux32/opt-mochitest-e10s-1 tc-M-e10s(1)" launches

/home/worker/workspace/build/tests/mochitest/runtests.py --total-chunks
10 --this-chunk 1
--appname=/home/worker/workspace/build/application/firefox/firefox
--utility-path=tests/bin --extra-profile-file=tests/bin/plugins

Using --appname. As expected, this then fails because the sandbox didn't
get the exception added and correctly blocks the reading of some test
files that are in a random place:

/home/worker/workspace/build/tests/mochitest/extensions/specialpowers/chrome/specialpowers/content/MozillaLogger.js

We may need another solution here.

-- 
GCP
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Running mochitest on packaged builds with the sandbox

[Nathan Froyd]

On Mon, May 8, 2017 at 1:26 PM, Alex Gaynor  wrote:
> Top-line question: Do you rely on being able to run mochitests from a
> packaged build (`--appname`)?

I don't think it's a *fundamental* part of development workflows, but
I know folks have found value in being able to run tests--including
but not limited to mochitest--against packaged builds (release
versions, beta versions, whatever).  It would be nice to not break
that, or at least provide obvious escape hatches where possible.

-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Running mochitest on packaged builds with the sandbox

[Ehsan Akhgari]

On 05/09/2017 11:02 AM, Alex Gaynor wrote:

Hi Ehsan,

If we want to dig deeper, let's fork off another thread, but it sounds 
like there's two action items here:


1) Fix https://bugzilla.mozilla.org/show_bug.cgi?id=1345046
2) Better document how to disable the sandbox for debugging -- where 
would you expect to find docs on this, 
https://wiki.mozilla.org/Security/Sandbox, somewhere else?


I really think we should do #1 if at all possible.  If that's not an 
option, I think we should print out something helpful to stderr when we 
see the logging environment variables pointing to a file name in a 
sandboxed content process, the problem with picking a wiki page like 
above is that most people won't immediately realize that it's sandboxing 
that makes the log files not get generated and start wasting time 
debugging things until they get to that conclusion and it is only then 
when they start to search for relevant documentation in a place related 
to sandboxing.


Now let's go back to discussing the actual topic of the thread. Thanks 
for indulging the momentary digression from the topic at hand.  :-)


Cheers,
Ehsan


Cheers,
Alex

On Tue, May 9, 2017 at 10:49 AM, Ehsan Akhgari 
> wrote:


Hi Alex,

Apologies for hijacking the thread, but since you asked, right now
debugging mochitest that you want to get some logging out of with
a sandboxed content process is super painful.  I last hit it when
I was debugging a memory leak which typically requires getting
refcount leak logs and it took me quite a while to find the wiki
page that describes the pref that I needed to set in order to turn
off the sandbox so that any logging in the content process would
be able to write to a log file (and I couldn't even find it again
to include a link to the wiki page here once again!).

I thought I'd mention it since you were asking about stuff that
can be painful when debugging test failures with sandboxed content
processes.  :-)

Thanks,

Ehsan



On 05/08/2017 01:26 PM, Alex Gaynor wrote:

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





___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Running mochitest on packaged builds with the sandbox

[Alex Gaynor]

Hi Ehsan,

If we want to dig deeper, let's fork off another thread, but it sounds like
there's two action items here:

1) Fix https://bugzilla.mozilla.org/show_bug.cgi?id=1345046
2) Better document how to disable the sandbox for debugging -- where would
you expect to find docs on this, https://wiki.mozilla.org/Security/Sandbox,
somewhere else?

Cheers,
Alex

On Tue, May 9, 2017 at 10:49 AM, Ehsan Akhgari 
wrote:

> Hi Alex,
>
> Apologies for hijacking the thread, but since you asked, right now
> debugging mochitest that you want to get some logging out of with a
> sandboxed content process is super painful.  I last hit it when I was
> debugging a memory leak which typically requires getting refcount leak logs
> and it took me quite a while to find the wiki page that describes the pref
> that I needed to set in order to turn off the sandbox so that any logging
> in the content process would be able to write to a log file (and I couldn't
> even find it again to include a link to the wiki page here once again!).
>
> I thought I'd mention it since you were asking about stuff that can be
> painful when debugging test failures with sandboxed content processes.  :-)
>
> Thanks,
>
> Ehsan
>
>
>
> On 05/08/2017 01:26 PM, Alex Gaynor wrote:
>
>> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Running mochitest on packaged builds with the sandbox

[Alex Gaynor]

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 
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

Re: Running mochitest on packaged builds with the sandbox

[Ehsan Akhgari]

Hi Alex,

Apologies for hijacking the thread, but since you asked, right now 
debugging mochitest that you want to get some logging out of with a 
sandboxed content process is super painful.  I last hit it when I was 
debugging a memory leak which typically requires getting refcount leak 
logs and it took me quite a while to find the wiki page that describes 
the pref that I needed to set in order to turn off the sandbox so that 
any logging in the content process would be able to write to a log file 
(and I couldn't even find it again to include a link to the wiki page 
here once again!).


I thought I'd mention it since you were asking about stuff that can be 
painful when debugging test failures with sandboxed content processes.  :-)


Thanks,

Ehsan


On 05/08/2017 01:26 PM, Alex Gaynor wrote:

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

RE: Running mochitest on packaged builds with the sandbox

[Kearwood Kip Gilbert]

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