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)
Tracking
()
RESOLVED
FIXED
mozilla39
People
(Reporter: mconley, Assigned: areinald.bug)
References
Details
Attachments
(1 file)
3.02 KB,
application/x-compressed
|
Details |
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.
Comment 2•9 years ago
|
||
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
Comment 3•9 years ago
|
||
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
Assignee | ||
Comment 4•9 years ago
|
||
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 | ||
Updated•9 years ago
|
Assignee: nobody → areinald
Version: 32 Branch → 38 Branch
Comment 5•9 years ago
|
||
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.
Assignee | ||
Comment 6•9 years ago
|
||
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.
Comment 7•9 years ago
|
||
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.
Assignee | ||
Comment 9•9 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1083344#c137
Assignee | ||
Comment 10•9 years ago
|
||
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.
Comment 11•9 years ago
|
||
(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
Comment 12•9 years ago
|
||
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
Assignee | ||
Comment 13•9 years ago
|
||
(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.
Comment 14•9 years ago
|
||
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.
Assignee | ||
Comment 15•9 years ago
|
||
(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?
Comment 16•9 years ago
|
||
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.
Reporter | ||
Comment 17•9 years ago
|
||
(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.
Comment 18•9 years ago
|
||
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.
Assignee | ||
Comment 19•9 years ago
|
||
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.
Assignee | ||
Comment 20•9 years ago
|
||
(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.
Reporter | ||
Comment 21•9 years ago
|
||
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?
Assignee | ||
Comment 22•9 years ago
|
||
(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.
Comment 23•9 years ago
|
||
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.
Comment 24•9 years ago
|
||
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
Assignee | ||
Comment 25•9 years ago
|
||
(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.
Comment 27•9 years ago
|
||
(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?
Assignee | ||
Comment 29•9 years ago
|
||
(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.
Comment 32•9 years ago
|
||
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.
I filed bug 1136836 for the chrome URL issue.
Comment 34•9 years ago
|
||
(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.
Comment 35•9 years ago
|
||
(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.
Comment 37•9 years ago
|
||
> 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.
Comment 38•9 years ago
|
||
>> 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?
Comment 39•9 years ago
|
||
>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.
Comment 42•9 years ago
|
||
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.
Comment 43•9 years ago
|
||
> 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
Comment 45•9 years ago
|
||
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.
Reporter | ||
Comment 46•9 years ago
|
||
(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.
Comment 47•9 years ago
|
||
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
Comment 48•9 years ago
|
||
(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.
Comment 49•9 years ago
|
||
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.
Comment 50•9 years ago
|
||
(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
status-firefox39:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Comment 53•9 years ago
|
||
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?
status-firefox38:
--- → affected
Flags: needinfo?(areinald)
Assignee | ||
Comment 54•9 years ago
|
||
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.
Comment 55•9 years ago
|
||
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.
Assignee | ||
Comment 56•9 years ago
|
||
Patch above made default to 0. We're currently at step 2. See bug 1083344.
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(areinald)
You need to log in
before you can comment on or make changes to this bug.
Description
•