Closed Bug 1136407 Opened 9 years ago Closed 9 years ago

Tighter sandboxing rules are breaking mochitests on OS X 10.9 and 10.10

Categories

(Core :: Security: Process Sandboxing, defect)

38 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla39
Tracking Status
firefox38 --- affected
firefox39 --- fixed

People

(Reporter: mconley, Assigned: areinald.bug)

References

Details

Attachments

(1 file)

There are multiple / varied reports of mochitests not working properly lately, and bisection has revealed bug 1083344 to be the likely culprit.

In the one case I know of, the global message manager is loading frame scripts far too late in the content process with bug 1083344.

I believe bkelly and handyman have also seen similar failures - I believe one has to do with SpecialPowers being undefined, and RunSet being undefined in SimpleTest/setup.js.

This only seems to affect 10.9 and 10.10.
Any idea what's going on here, areinald?
Flags: needinfo?(areinald)
Ya I'm hitting this in Bug 1093566. There is about a 5 second delay before my frame script is loaded in a new browser (I've added it from the global message manager). OSX 10.9
Blocks: 1093566
It might be obvious, but since I bisected this, the commit that actually breaks things in Bug 1093566's case, is the "rules part" not the "core part". i.e. the first broken changeset is http://hg.mozilla.org/mozilla-central/rev/8c11efebc455
The base line is that sandboxing is likely impossible to get right at this point, as way too many resources are used by the content process. See Bug 1124817.

I can't explain for sure why additional delays occur in tests. I guess we're hitting timeouts in some async calls, which will then return a default result, which in some cases is treated right, but late.

The aim was for sandboxing to ride the next train. I will ask for aurora approval once I have more (but likely not all) mochitests running on 10.9 and 10.10. In other words, as I understood it, regressions are to be expected, but the fewer, the better. And the solution will not systematically be to punch more holes in the already far-from-perfect sandbox.

In the rules, I intentionally left a "debug deny" so that failures due to denials will leave a trace in the system log. Once I have an automated test environment set up, I will be able to spot (and correct) more failures myself. In the meantime it would help if you can attach the result of a grep -i "sandbox|deny|denied" on the system log while tests are running, I will either add a few more "allow" rules, or explain why we should not.
Flags: needinfo?(areinald)
Assignee: nobody → areinald
Version: 32 Branch → 38 Branch
It'd really help if people gave specific examples of tests that are failing (or at least misbehaving), together with instructions how to run them locally.
I assigned the bug to myself as I worked on mac sandboxing for a while and I may be the best fit for this bug. Unless someone else wants to take it.
Go for it, André! :-)

I was only trying to get others to make your task easier.
I think we should disable the sandbox until this is fixed. It seems like a showstopper for people developing on 10.9 or 10.10.
e10s is riding the trains but is disabled by default in final releases.

I basically propose we do the same with sandboxing. It's just a matter of setting level=0 for final.

We need real world exposure at least in aurora and beta so we realize what remains be done to run into a proper sandbox (and this one is already too loose).

Meanwhile, I'm still willing to take grepped system log files to adjust current rules where it seems wise.
(In reply to Bill McCloskey (:billm) from comment #8)
> I think we should disable the sandbox until this is fixed. It seems like a
> showstopper for people developing on 10.9 or 10.10.
That would be my vote as well. This broke my tests in a really strange way I would have never expected and I had to spend far too long tracking it down.


(In reply to André Reinald from comment #10)
> Meanwhile, I'm still willing to take grepped system log files to adjust
> current rules where it seems wise.
Here you go:
> Feb 25 09:26:43 SSMobile04 kernel[0]: firefox (map: 0xffffff8065d9d4b0) triggered DYLD shared region unnest for map: 0xffffff8065d9d4b0, region 0x7fff96400000->0x7fff96600000. While not abnormal for debuggers, this increases system memory footprint until the target exits.
> Feb 25 09:26:47 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /private/var/folders/3v/h4r8wwqs41g_p4cfmv8sqty80000gn/T/tmp2Ssrmd.mozrunner/extensions/special-powers@mozilla.org/chrome/specialpowers/content/MozillaLogger.js
> Feb 25 09:26:47 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /private/var/folders/3v/h4r8wwqs41g_p4cfmv8sqty80000gn/T/tmp2Ssrmd.mozrunner/extensions/special-powers@mozilla.org/chrome/specialpowers/content/specialpowersAPI.js
> Feb 25 09:26:47 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /private/var/folders/3v/h4r8wwqs41g_p4cfmv8sqty80000gn/T/tmp2Ssrmd.mozrunner/extensions/special-powers@mozilla.org/chrome/specialpowers/content/specialpowers.js
> Feb 25 09:26:47 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /private/var/folders/3v/h4r8wwqs41g_p4cfmv8sqty80000gn/T/tmp2Ssrmd.mozrunner/extensions/mochikit@mozilla.org/chrome/mochikit.jar
> Feb 25 09:26:47 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app
> Feb 25 09:26:47 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app/Contents
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app/Contents
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app/Contents
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app/Contents
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app/Contents
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app/Contents
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /Applications/Sublime Text.app/Contents
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /private/var/folders/3v/h4r8wwqs41g_p4cfmv8sqty80000gn/T/tmp2Ssrmd.mozrunner/extensions/special-powers@mozilla.org/chrome/specialpowers/content/MozillaLogger.js
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /private/var/folders/3v/h4r8wwqs41g_p4cfmv8sqty80000gn/T/tmp2Ssrmd.mozrunner/extensions/special-powers@mozilla.org/chrome/specialpowers/content/specialpowersAPI.js
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /private/var/folders/3v/h4r8wwqs41g_p4cfmv8sqty80000gn/T/tmp2Ssrmd.mozrunner/extensions/special-powers@mozilla.org/chrome/specialpowers/content/specialpowers.js
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /private/var/folders/3v/h4r8wwqs41g_p4cfmv8sqty80000gn/T/tmp2Ssrmd.mozrunner/extensions/mochikit@mozilla.org/chrome/mochikit.jar
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: appleeventsd(100) deny file-read-data /Users/smacleod/src/moz/fx/wds/pb-tests/obj-x86_64-apple-darwin13.4.0/dist/NightlyDebug.app/Contents/MacOS/plugin-container.app
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: appleeventsd(100) deny file-read-metadata /Users/smacleod/src/moz/fx/wds/pb-tests/obj-x86_64-apple-darwin13.4.0/dist/NightlyDebug.app/Contents/MacOS/plugin-container.app/Contents
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: appleeventsd(100) deny file-read-metadata /Users/smacleod/src/moz/fx/wds/pb-tests/obj-x86_64-apple-darwin13.4.0/dist/NightlyDebug.app/Contents/MacOS/plugin-container.app
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: appleeventsd(100) deny file-read-data /Users/smacleod/src/moz/fx/wds/pb-tests/obj-x86_64-apple-darwin13.4.0/dist/NightlyDebug.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container
> Feb 25 09:26:48 SSMobile04.local appleeventsd[100]: <rdar://problem/11489077> A sandboxed application with pid 62646, "Nightly Web Content" checked in with appleeventsd, but its code signature could not be validated ( either because it was corrupt, or could not be read by appleeventsd ) and so it cannot receive AppleEvents targeted by name, bundle id, or signature. Error=ERROR: #100001  { "NSDescription"="SecCodeCopyGuestWithAttributes() returned 100001, -." }  (handleMessage()/appleEventsD.cp #2072) client-reqs-q
> Feb 25 09:26:48 SSMobile04.local lsboxd[304]: Denied process 62646(UNKNOWN) access to shared list org.mozilla.plugincontainer.LSSharedFileList
> Feb 25 09:26:53 SSMobile04.local sandboxd[55057] ([62646]): plugin-container(62646) deny file-read-data /Applications/Sublime Text.app
> Feb 25 09:26:53 SSMobile04.local sandboxd[55057] ([62646]): plugin-container(62646) deny file-read-data /Applications/Sublime Text.app/Contents
> Feb 25 09:26:53 SSMobile04.local sandboxd[55057] ([62646]): plugin-container(62646) deny file-read-data /Applications/Xcode.app/Contents/Developer/Applications/iOS Simulator.app
> Feb 25 09:26:53 SSMobile04.local sandboxd[55057] ([62646]): plugin-container(62646) deny file-read-data /Applications/Xcode.app/Contents/Developer/Applications/iOS Simulator.app/Contents
> Feb 25 09:26:53 SSMobile04.local sandboxd[55057] ([62646]): plugin-container(62646) deny file-read-data /Applications/Xcode.app/Contents/Developer/Applications/iOS Simulator.app/Contents/Resources
> Feb 25 09:26:53 SSMobile04.local sandboxd[55057] ([62646]): plugin-container(62646) deny file-read-data /Applications/Xcode.app/Contents/Developer/Applications/iOS Simulator.app/Contents/MacOS/iOS Simulator/..namedfork/rsrc
> Feb 25 09:26:53 SSMobile04.local sandboxd[55057] ([62646]): plugin-container(62646) deny file-read-data /Applications/Xcode.app/Contents/Developer/Applications/iOS Simulator.app/Contents/Resources
> Feb 25 09:26:53 SSMobile04.local sandboxd[55057] ([62646]): plugin-container(62646) deny file-read-data /Applications/Sublime Text.app
Also FWIW, maybe the following is what's tripping up my test:
> Feb 25 09:26:48 SSMobile04 kernel[0]: Sandbox: plugin-container(62646) deny file-read-data /private/var/folders/3v/h4r8wwqs41g_p4cfmv8sqty80000gn/T/tmp2Ssrmd.mozrunner/extensions/mochikit@mozilla.org/chrome/mochikit.jar
Seeing as my framescript is packaged in mochikit.jar
(In reply to Steven MacLeod [:smacleod] from comment #11)
> (In reply to Bill McCloskey (:billm) from comment #8)
> > I think we should disable the sandbox until this is fixed. It seems like a
> > showstopper for people developing on 10.9 or 10.10.
> That would be my vote as well. This broke my tests in a really strange way I
> would have never expected and I had to spend far too long tracking it down.
> 
> (In reply to André Reinald from comment #10)
> > Meanwhile, I'm still willing to take grepped system log files to adjust
> > current rules where it seems wise.
> Here you go:

Thanks for the log. From what I can read, the alarming denials are, as I expected, related to test specific needs. I think it's ok to add allow rules here, though I believe it makes no sense to carry them on in final builds. But we're weeks if not months from that.
You mean, add specific exceptions for particular tests?  If so, I'll need some instructions.  The failing tests in my case are in patches that have not yet landed yet.
(In reply to Ben Kelly [:bkelly] from comment #14)
> You mean, add specific exceptions for particular tests?  If so, I'll need
> some instructions.  The failing tests in my case are in patches that have
> not yet landed yet.

I mean /private/var/folders/XX/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/X/XXXXXXXXX.mozrunner/ subdirectories.
We already have special-powers and mochikit there.

Do you think you'd need access in another directory?

Can you paste the relevant portion of your system log as explained in comment 4?
Attached file logs.txt.gz
Here are my logs.  I produced it with:

gzcat /var/log/system.log.0.gz | grep -i sandbox | grep -v LINE

Not sure if that's the grep you had in mind.

Thanks.
(In reply to André Reinald from comment #10)
> e10s is riding the trains but is disabled by default in final releases.

So we're clear, e10s is restricted to Nightly only. It has not been cleared to uplift to Aurora.
So what is the next step in adding the rules I need? I want to get this testing stuff landed ASAP and sandboxing is really holding me back.

Also, it would be extremely helpful to have things blocked by the sandbox show up in the console log or something, rather than just the system log. It would have saved me many hours.
After some more grepping on your log, it boils down to the same pattern:

/private/var/folders/XX/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/X/XXXXXXXXX.mozrunner/

Thanks!

Still waiting for other's logs so I may detect additional patterns to allow.
(In reply to Steven MacLeod [:smacleod] from comment #18)
> So what is the next step in adding the rules I need? I want to get this
> testing stuff landed ASAP and sandboxing is really holding me back.

For now, just change the default sandbox level=1 to level=0. I will post my patch here later today or tomorrow.

> Also, it would be extremely helpful to have things blocked by the sandbox
> show up in the console log or something, rather than just the system log. It
> would have saved me many hours.

I'm afraid there is no way to log denied accesses in the console. The system is responsible for sandbox denial logging, and there is no control from the app side to tell it where to log.
Possibly dumb question:

Looking at treeherder, I don't see any tests being run on 10.9 or 10.10 machines. We just have 10.6 and 10.8 being displayed, as far as I can tell.

We now know that if we _had_ machines running 10.9/10.10 in our testing infrastructure, bug 1083344 would have oranged like crazy, and probably bounced.

The lack of test coverage for 10.9 and 10.10 is a little concerning here. Do we know of any plans to have 10.9 or 10.10 machines exist in the testing pool?
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #17)
> So we're clear, e10s is restricted to Nightly only. It has not been cleared
> to uplift to Aurora.

I'm not sure where e10s is enabled by default. The DevEdition today is v37, which is the same as Aurora, I don't remember having changed a setting, and it's definitely running e10s.

But you're right to highlight that sandboxing is dependent on e10s which is not enabled mainstream yet.
I've occasionally seen the DevEdition running e10s, but (as best I can tell) this only happens if you also use m-c nightlies on your DevEdition profile, and set *them* to use e10s.
According to https://dataviz.mozilla.org/views/PlatformVersionFirefoxADI/OSXDetails, the # of nightly users has been stable around 1800-2000 since October for Mavericks + Yosemite combined
(In reply to Steven Michaud from comment #23)
> I've occasionally seen the DevEdition running e10s, but (as best I can tell) this only happens if you also use m-c nightlies on your DevEdition profile, and set *them* to use e10s.

Oh! That's probably why I have e10s enabled in DevEdition. Thanks!
I talked to Brad and he agreed we should disable the sandbox until this is fixed. It seems likely that this will affect actual users and not just testing, especially if they have add-ons installed.

e10s is effectively disabled on aurora and beta. You can turn it on if you want, but hopefully no one does. Large parts of e10s are #ifdef NIGHTLY, so it would be very broken.

In any case, there's no need to backport the sandbox.
(In reply to Bill McCloskey (:billm) from comment #26)
> e10s is effectively disabled on aurora and beta. You can turn it on if you
> want, but hopefully no one does. Large parts of e10s are #ifdef NIGHTLY, so
> it would be very broken.

If this is true, shouldn't we hard disable e10s completely in non-nightly to prevent accidental enablement via shared profiles?
(In reply to Bill McCloskey (:billm) from comment #26)
> I talked to Brad and he agreed we should disable the sandbox until this is
> fixed. It seems likely that this will affect actual users and not just
> testing, especially if they have add-ons installed.

bsmedberg actually *wants* misbehaving add-ons to break. Any minimal sandbox we come up with will disallow reading into ~/Library at least.

> e10s is effectively disabled on aurora and beta. You can turn it on if you
> want, but hopefully no one does. Large parts of e10s are #ifdef NIGHTLY, so
> it would be very broken.

As sandboxing depends on e10s, what's the point of changing the "level" setting then?
(In reply to Ben Kelly [:bkelly] from comment #27)
> (In reply to Bill McCloskey (:billm) from comment #26)
> > e10s is effectively disabled on aurora and beta. You can turn it on if you
> > want, but hopefully no one does. Large parts of e10s are #ifdef NIGHTLY, so
> > it would be very broken.
> 
> If this is true, shouldn't we hard disable e10s completely in non-nightly to
> prevent accidental enablement via shared profiles?

I just checked and it looks like we only enable e10s on non-nightly if both browser.tabs.remote and layers.offmainthreadcomposition.testing.enabled are enabled. The latter pref is intended to be set only on tinderbox machines so they can run remote reftests. So I'm not sure how anyone is getting e10s on aurora.
(In reply to André Reinald from comment #29)
> bsmedberg actually *wants* misbehaving add-ons to break. Any minimal sandbox
> we come up with will disallow reading into ~/Library at least.

From this bug, it sounds like any add-on that tries to load a frame script will be broken. That's not an example of misbehavior--we *want* add-ons to be using frame scripts.

The problem here is that we haven't laid enough of the foundation yet for sandboxing to be practical. It sounds like we need to load chrome URIs through the parent process rather than doing it through the file system.

I'm afraid I don't know much about MacOS though. What is stored in ~/Library? Presumably the profile?

> > e10s is effectively disabled on aurora and beta. You can turn it on if you
> > want, but hopefully no one does. Large parts of e10s are #ifdef NIGHTLY, so
> > it would be very broken.
> 
> As sandboxing depends on e10s, what's the point of changing the "level"
> setting then?

I'm not sure I understand. If we set level to 1, then Nightly users will get a sandbox. We have a decent number of Nightly users (I've heard around 50,000), including most Firefox devs.
After talking with Bill, I suspect this is why BugzillaJS is broken as well. In my system.log I have several instances of: 

Feb 25 13:11:50 flyingfox-2 kernel[0]: Sandbox: plugin-container(64978) deny file-read-data /Users/blassey/Library/Application Support/Firefox/Profiles/egt7s62z.Default User/extensions/jid0-NgMDcEu2B88AbzZ6ulHodW9sJzA@jetpack.xpi


which is presumably the attempt to load BugzillaJS's framescript.
(In reply to comment #31)

> it sounds like any add-on that tries to load a frame script will be broken

Is this covered by bug 1136836?  If not, please expand on it in as much detail as possible -- including a description of what a "frame script" is.

There are several things that will need to be brokered through the main process (from the content process) before truly secure content process sandboxing is possible.  Here's what I currently know about.  The list will probably need to be expanded.

1) The native filepicker dialog (which among other things accesses files directly).
2) The native print and page setup dialogs (which access files and lots of other services).
3) Several other kinds of file access (bug 1124817).
4) Loading chrome URLs (bug 1136836).
5) All extension access to anything in the browser profile.
(Following up comment #34)

Oops, forgot to add the following:

6) Camera and microphone access (bug 1104615).
(In reply to Steven Michaud from comment #34)
> (In reply to comment #31)
> 
> > it sounds like any add-on that tries to load a frame script will be broken
> 
> Is this covered by bug 1136836?  If not, please expand on it in as much
> detail as possible -- including a description of what a "frame script" is.

Yes, that's correct. A frame script is the main way that we load JS code into the content process. I linked to the documentation in the bug.

> There are several things that will need to be brokered through the main
> process (from the content process) before truly secure content process
> sandboxing is possible.  Here's what I currently know about.  The list will
> probably need to be expanded.
> 
> 1) The native filepicker dialog (which among other things accesses files
> directly).

We use a proxy for the file picker in the content process and it's designed to avoid access to the file system. It uses blobs to refer to files, so all the file access is supposed to be done by the parent. It's possible there are bugs though. Have you tested it or is it just a theoretical issue?

> 2) The native print and page setup dialogs (which access files and lots of
> other services).
> 3) Several other kinds of file access (bug 1124817).
> 4) Loading chrome URLs (bug 1136836).
> 5) All extension access to anything in the browser profile.

The last issue probably isn't such a big problem. Add-ons run in the parent process by default and they're allowed to access the profile there.
> We use a proxy for the file picker in the content process ...

Filepickers are different on the Mac than on all other platforms.  They're native on the Mac, and non-native on Windows and Linux.  We'll definitely have to proxy all native dialogs (including the print and page setup dialogs) through the main process.

And no, this isn't just a theoretical issue.  It was revealed by problems I found at bug 1083344 using these dialogs.
>> 5) All extension access to anything in the browser profile.
>
> The last issue probably isn't such a big problem. Add-ons run in the
> parent process by default and they're allowed to access the profile
> there.

Glad to hear this ... at least from the point of view of sandbox
complexity.  Obviously, though, it's not so good that extensions have
such privileged access.  Do we have medium or long term plans to run
extensions in a separate process (or processes)?  If so are there bug
numbers?
>They're native on the Mac, and non-native on Windows and Linux.
We have use native filepickers on Windows and Linux as well. Are you talking about the same thing? i.e clicking on an <input type=file> ?
(In reply to Tom Schuster [:evilpie] from comment #39)
> >They're native on the Mac, and non-native on Windows and Linux.
> We have use native filepickers on Windows and Linux as well. Are you talking
> about the same thing? i.e clicking on an <input type=file> ?

And to clarify, <input type=file> is the only time we should be opening a file picker in the content process. Things like "Save X As..." open the file picker in the parent process, although they do other stuff in the content process that might be broken by sandboxing.
(In reply to Steven Michaud from comment #38)
> Glad to hear this ... at least from the point of view of sandbox
> complexity.  Obviously, though, it's not so good that extensions have
> such privileged access.  Do we have medium or long term plans to run
> extensions in a separate process (or processes)?  If so are there bug
> numbers?

It's unlikely that traditional XUL add-ons could ever run in a separate process. We could probably do it for Jetpack add-ons, but there aren't any plans to do so. There has been some talk of future add-on models, and those would surely use a separate process.
Perhaps it depends on what you mean by "native".

On the Mac, our filepickers and "print" and "page setup" dialogs are actually provided by the OS.  And the OS code in those dialogs accesses files and OS services directly -- so the dialogs will need to be launched from the main process.
> so the dialogs will need to be launched from the main process

so these dialogs will *always* need to be launched from the main process
Well, the Mac implementation I'm aware of is in nsFilePicker.mm. It's not used in the content process. You can see the MAIN_PROCESS_ONLY flag here:
http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsWidgetFactory.mm#161

Instead we use the implementation in nsFilePickerProxy.cpp. That happens here:
http://mxr.mozilla.org/mozilla-central/source/widget/nsContentProcessWidgetFactory.cpp#34
I guess I'll have to take another look to be sure about the filepickers.

But I'm quite sure that the "print" and "page setup" dialogs currently run from the content process in e10s mode, and that they should always run from the main process.
(In reply to Steven Michaud from comment #45)
> 
> But I'm quite sure that the "print" and "page setup" dialogs currently run
> from the content process in e10s mode, and that they should always run from
> the main process.

Yes, this is true. Getting them to open in the parent process is something I'd like to do soonish, but we felt that opening in the content process was fine for now as a short-term solution.
You can see some failures in our soon-to-be-deployed 10.10 tests in automation, https://treeherder.mozilla.org/#/jobs?repo=try&revision=2377ad0190d1
(In reply to Bill McCloskey (:billm) from comment #40)
> Things like "Save X As..." open the file
> picker in the parent process, although they do other stuff in the content
> process that might be broken by sandboxing.

e10s “Save As” shouldn't be a problem, and I should be able to get it to feature parity with non-e10s “Save As” without introducing sandboxing problems; see also bug 1101100.
I wrote a handy interpose library to check ... and I found out that *both* the filepicker and the "Page Setup" dialog run from the main process.  Only the Print dialog doesn't (at least in normal usage).  In all cases I opened these dialogs using a menu command or menu shortcut.  This was in a fairly recent m-c nightly (and in e10s mode, of course).

I stand corrected ... and also relieved that more work has already been done than I first realized.
(In reply to Bill McCloskey (:billm) from comment #36)
> (In reply to Steven Michaud from comment #34)
> > 5) All extension access to anything in the browser profile.
> 
> The last issue probably isn't such a big problem. Add-ons run in the parent
> process by default and they're allowed to access the profile there.

Right but we are also pushing add-on developers to use frame scripts to do things in content rather than relying on CPOWs. Many add-ons (SDK based ones in particular) use the resource protocol to help them get a their files.

(In reply to Bill McCloskey (:billm) from comment #41)
> (In reply to Steven Michaud from comment #38)
> > Glad to hear this ... at least from the point of view of sandbox
> > complexity.  Obviously, though, it's not so good that extensions have
> > such privileged access.  Do we have medium or long term plans to run
> > extensions in a separate process (or processes)?  If so are there bug
> > numbers?
> 
> It's unlikely that traditional XUL add-ons could ever run in a separate
> process. We could probably do it for Jetpack add-ons, but there aren't any
> plans to do so. There has been some talk of future add-on models, and those
> would surely use a separate process.

We abandoned our plans to do this for the SDK the last time e10s got killed. Even then it was looking very difficult to do.
https://hg.mozilla.org/mozilla-central/rev/3ed19dfc6443
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
OSX 10.10 tests are being enabled on Aurora38 as well, so I assume we need this patch there as well. Can you please request Aurora approval?
Flags: needinfo?(areinald)
I guess you mean by "this patch" https://hg.mozilla.org/mozilla-central/rev/3ed19dfc6443
There should be a decision this afternoon about taking one of the 2 following paths:
- uplift "this patch" to Aurora (setting the default sandbox level to 0)
- or applying and maybe uplifting the last patch in 1083344

I keep the needinfo flag on as a reminder.
In the sandbox meeting, we decided that we will:

- temporarily disable OS X sandbox (default to sandbox level 0)
- then switch to level 1 plus exceptions
- then fix level 2 without exceptions by brokering OS X print dialog/etc.
Patch above made default to 0.
We're currently at step 2. See bug 1083344.
Flags: needinfo?(areinald)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: