Closed Bug 1296089 Opened 5 years ago Closed 5 years ago

[e10s] Tab crashes if a userContent.css exists in the profile


(Core :: Security: Process Sandboxing, defect)

51 Branch
Not set



Tracking Status
e10s + ---
firefox48 --- wontfix
firefox51 --- affected


(Reporter: MattN, Assigned: wcpan)



(Keywords: crash, regression, topcrash-mac)

Crash Data


(1 file)

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

Triggered by:
d1d614497fbf	Wei-Cheng Pan — Bug 1046166 - Send userContent.css URL to content processes. r=dbaron

By reference to,
I set security.sandbox.content.level to 0 (default=1) on OS X.

That seems to fix the crash.
Component: CSS Parsing and Computation → Security: Process Sandboxing
This is a top crash on OSX Nightly.
Can you look into this regression, Wei-Cheng? It is causing a lot of crashes on Nightly. Thanks.
Flags: needinfo?(wpan)
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?
Flags: needinfo?(haftandilian)
Assignee: nobody → wpan
Flags: needinfo?(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.
Flags: needinfo?(haftandilian)
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?
Flags: needinfo?(wpan)
Tested on my Mac, it will return NS_ERROR_NOT_AVAILABLE at here:

I guess I need to find a way to AsyncOpen the file to fix the root cause.
Flags: needinfo?(wpan)
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.
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.