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

Status: RESOLVED WORKSFORME

(Core :: Security: Process Sandboxing, defect)

Description

[Matthew N. [:MattN]]

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

Comment 1

[Matthew N. [:MattN]]

bp-49bc914c-1625-4b21-9edf-ff5792160817

Comment 2

[Eiichi]

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.

Comment 3

[Andrew McCreight [:mccr8]]

This is a top crash on OSX Nightly.

Comment 4

[Andrew McCreight [:mccr8]]

Can you look into this regression, Wei-Cheng? It is causing a lot of crashes on Nightly. Thanks.

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

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?

Comment 6

[Wei-Cheng Pan [:wcpan] [:wcp] [:legnaleurc] (left Mozilla)]

Tried on Linux with security.sandbox.content.level=1, didn't crash.

Now I'm trying on Mac and Windows.

Comment 7

[Haik Aftandilian [:haik]]

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.

Comment 8

[Haik Aftandilian [:haik]]

Attachment: Patch that lets content process read from $PROFILE/chrome

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?

Comment 9

[Wei-Cheng Pan [:wcpan] [:wcp] [:legnaleurc] (left Mozilla)]

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.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 11

[Jim Mathies [:jimm]]

original patch was backed out.