+++ This bug was initially created as a clone of Bug #1295990 +++ This is like bug 1295990 but without a network share involved. * The crash does not occur if userContent.css does not exist. Steps To Reproduce: 1. Create userContent.css in the chrome directory of your local profile. Actual Results: Remote tabs crash Expected Results: Tab should be properly loaded and also applied userContent.css Likely the same regression window as bug 1295990: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a94448be42e2b6db4630cc120a3c1bf30374451d&tochange=d1d614497fbfc0cc14cd923037ba014b1a503119 Triggered by: d1d614497fbf Wei-Cheng Pan — Bug 1046166 - Send userContent.css URL to content processes. r=dbaron 49bc914c-1625-4b21-9edf-ff5792160817
By reference to https://bugzilla.mozilla.org/show_bug.cgi?id=1295990#c4, I set security.sandbox.content.level to 0 (default=1) on OS X. That seems to fix the crash.
Can you look into this regression, Wei-Cheng? It is causing a lot of crashes on Nightly. Thanks.
It looks like this is a fixed pathname relative to the profile, not something the user can set/change at runtime — can we just add a sandbox policy rule to allow this file?
3 years ago
Assignee: nobody → wpan
Tried on Linux with security.sandbox.content.level=1, didn't crash. Now I'm trying on Mac and Windows.
On Nightly, Mac is the only platform that blocks read access to the profile directory from the content process. Mac blocks read access to ~/Library which normally contains the profiles. Only $PROFILE/extensions and $PROFILE/weave are allowed to be accessed from content. The content sandbox is only enabled on Nightly, so this shouldn't be a problem on any other releases. We can add a rule for now to the content sandbox that allows reads from $PROFILE/chrome. My understanding is we don't expect there to be anything security sensitive there. This needs to be tested with the backed out fix for 1046166. Note that if the profile is located within ~/Library, but not in Application Support/Firefox/Profiles, the problem will still occur. That will be fixed by Bug 1290619.
This patch modifies the content process to allow the content process to read from $PROFILE/chrome. Wei-Cheng, could you confirm this fixes the problem with the backed out patch for 1046166?
Tested on my Mac, it will return NS_ERROR_NOT_AVAILABLE at here: https://dxr.mozilla.org/mozilla-central/rev/052656fc513c05da969590ac5934abd67271a897/netwerk/protocol/file/nsFileProtocolHandler.cpp#104 I guess I need to find a way to AsyncOpen the file to fix the root cause.
Crash volume for signature 'mozalloc_abort | Abort | NS_DebugBreak | ErrorLoadingBuiltinSheet': - nightly (version 51): 164 crashes from 2016-08-01. - aurora (version 50): 0 crashes from 2016-08-01. - beta (version 49): 0 crashes from 2016-08-02. - release (version 48): 1 crash from 2016-07-25. - esr (version 45): 0 crashes from 2016-05-02. Crash volume on the last weeks (Week N is from 08-22 to 08-28): W. N-1 W. N-2 W. N-3 - nightly 164 0 0 - aurora 0 0 0 - beta 0 0 0 - release 0 0 0 - esr 0 0 0 Affected platform: Mac OS X Crash rank on the last 7 days: Browser Content Plugin - nightly #58 - aurora - beta - release #882 - esr
original patch was backed out.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.