Closed Bug 1422570 Opened 6 years ago Closed 6 years ago

Background image from userContent not applied in Linux with multiprocess enabled

Categories

(Core :: Security: Process Sandboxing, defect, P3)

57 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1386404
Tracking Status
firefox57 --- affected
firefox58 --- affected
firefox59 --- affected

People

(Reporter: nonecko, Assigned: gcp)

Details

(Whiteboard: sb+)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171128222554

Steps to reproduce:

I wrote color and images for background in userContent for a website and for about:home in Linux (Debian 9) and in in Windows. I tried enabling/disabling Stylo, graphic acceleration, OMTP and multiprocess.


Actual results:

In Linux with multiprocess enabled the images don't show up, just the colors. With multiprocess disabled the website background image shows up, the about:home one still doesn't.  


Expected results:

Images should show up.
1. Please either post the entire contents of the userContent.css file in a comment, or attach the file.
2. What pages or sites do you expect it to work on?
3. Does it work in a brand new profile?
https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles
Has STR: --- → no
Flags: needinfo?(nonecko)
Keywords: steps-wanted
Although it's not midget porn I will not post the content or the userContent file itself or the page/site, but here is an example that works (that doesn't work actually):

@-moz-document url("https://bugzilla.mozilla.org/") {

    #bugzilla-body {
        background-image: url("file:///home/K/Downloads/mozchomp.gif") !important;
        background-repeat: repeat-y !important;
        background-color: green !important;
    }
}

(it should change the background color of the center section to green and the red Godzilla head biting stuff from bug search loading screen should appear a few times at the left; however in Linux with multiprocess enabled the Godzilla head doesn't show up, it only changes the color)

What is important that I forgot to mention is it's a locally saved image, with a web address it works (image shows up with multiprocess enabled). This, for example, works fine: 

@-moz-document url("https://bugzilla.mozilla.org/") {

    #bugzilla-body {
        background-image: url("https://buI expect it to work on a few gzilla.mozilla.org/extensions/BMO/web/images/mozchomp.gif") !important;
        background-repeat: repeat-y !important;
        background-color: green !important;
    }
}

I tried new profiles, both on FF Release and Nightly, same results.
This is the code that should work, sorry for typing in the previous one:

@-moz-document url("https://bugzilla.mozilla.org/") {

    #bugzilla-body {
        background-image: url("https://bugzilla.mozilla.org/extensions/BMO/web/images/mozchomp.gif") !important;
        background-repeat: repeat-y !important;
        background-color: green !important;
    }
}

Another thing I noticed is userContent isn't reloaded when opening in new tab or window in Linux (Debian 9 at least) like it happens in Windows since a few FF versions.
Flags: needinfo?(nonecko)
Attached image userContent issue.gif
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Firefox: 59.0a1, Build ID: 20171218220523

I have managed to reproduce this issue on Windows 7 x64 using latest Nightly (59.0a1) build and latest Firefox (57.0.2) release. It's not reproducible if e10s is disabled.

Steps to reproduce:
1. Open Firefox browser and navigate to "about:support" page.
2. Click the "Open Folder" button beside the Profile Folder entry.
3. Create a folder named "chrome" in the directory that opens.
4. In the "chrome" folder create a css file with the name "userContent.css".
5. Copy the following code to userContent.css file:
Note: Download the gif from comment 3 and replace the path from the code with your path for the gif.

@-moz-document url("https://bugzilla.mozilla.org/") {

    #bugzilla-body {
        background-image: url("file:///C:/Users/cosmin.muntean/Desktop/mozchomp.gif") !important;
        background-repeat: repeat-y !important;
        background-color: green !important;
    }
}
6. Restart the browser.
7. Navigate to "https://bugzilla.mozilla.org/" page and observe the behavior.

[Expected results]:
- The Godzilla gif is displayed in the left of the page.

[Actual results]:
- The Godzilla gif is not displayed in the left of the page.

Attached a screen recording with the issue.
Status: UNCONFIRMED → NEW
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
Keywords: steps-wanted
Product: Firefox → Core
Priority: -- → P3
A workaround - add the image folder to "security.sandbox.content.read_path_whitelist" in about:config. In my example it would be "/home/K/Downloads/", not sure how to write the Windows location in Cosmin's example. 
I read about this here:
http://www.morbo.org/2017/11/linux-sandboxing-improvements-in.html
So it turns out it's not really a bug (nothing is broken) but security-for-freedom exchange.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
20171225220421

(In reply to Gingerbread Man from comment #5)
> Works for me, whether it's the remote file or local. I tested on a fresh
> profile.

I managed to get it to fail. I think it worked before because my Desktop and other such folders are in custom locations, rather than under the Users folder.
I also had my images outside c:/users, if I move them in the home folder it works (doesn't work actually). 
Adding the folder to read_path_whitelist key apparently isn't enough in Windows, file name must be included as well ("C:/Users/cosmin.muntean/Desktop/mozchomp.gif" for example). I also had to manually create the key.
read_path_whitelist is a Linux-specific pref. You will have to disable the sandbox itself or lower the sandbox level on Windows.
(In reply to K from comment #8)
> I also had my images outside c:/users, if I move them in the home folder it
> works (doesn't work actually).

Have you tried placing the image file next to userContent.css? That works for me.

background-image: url("mozchomp.gif") !important;
(In reply to Gingerbread Man from comment #10)
> (In reply to K from comment #8)
> > I also had my images outside c:/users, if I move them in the home folder it
> > works (doesn't work actually).
> 
> Have you tried placing the image file next to userContent.css? That works
> for me.
> 
> background-image: url("mozchomp.gif") !important;

Indeed it works, also with folders.

background-image: url("folder/mozchomp.gif") !important;

It never crossed my mind that the most logical location which looks like what is supposed to be used should be used.

(In reply to Masatoshi Kimura [:emk] from comment #9)
> read_path_whitelist is a Linux-specific pref. You will have to disable the
> sandbox itself or lower the sandbox level on Windows.

Most probably yes, but it also works if we add the key manually and put the full path including file name in it. 
At least for now it works.
Based on the discussion above, I believe this is a question for process sandboxing. I don't think the style system has anything to do with this.

I believe allowing content process to access random file on the disk is undesirable, and thus this restriction actually sounds reasonable. If you want to use local file in user content stylesheet, you should put the local file in some whitelist somehow (which I'm not familiar with).
Component: CSS Parsing and Computation → Security: Process Sandboxing
Flags: needinfo?(gpascutto)
(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #12)
> I believe allowing content process to access random file on the disk is
> undesirable, and thus this restriction actually sounds reasonable. If you
> want to use local file in user content stylesheet, you should put the local
> file in some whitelist somehow (which I'm not familiar with).

On Linux: yes; see comment #6.

Otherwise: the whitelist pref is Linux-specific (see comment #9), but on Windows[1] and Mac[2] the policy currently allows anything under the “chrome” folder (see comment #10 and comment #11), in contrast to Linux[3] where it's currently only the userContent.css file itself.

[1] https://searchfox.org/mozilla-central/rev/b24e6342d744c5a83fab5c15972e11eeb69d68e6/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp#532-534
[2] https://searchfox.org/mozilla-central/rev/b24e6342d744c5a83fab5c15972e11eeb69d68e6/security/sandbox/mac/SandboxPolicies.h#289
[3] https://searchfox.org/mozilla-central/rev/b24e6342d744c5a83fab5c15972e11eeb69d68e6/security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp#478
We should probably change Linux to whitelist the entire chrome folder, as on Mac on Windows. That will avoid the need to whitelist in most cases, although of course files in arbitrary locations won't ever work.
Assignee: nobody → gpascutto
Flags: needinfo?(gpascutto)
Is it possible to put some kind of warning or instructions for copying the image files in the chrome folder? Like a readme file inside the chrome folder, or a blank userContent with stuff written and commented out inside?
(In reply to K from comment #15)
> a blank userContent with stuff written and commented out inside?

The chrome folder used to exist by default, and it contained a userChrome-example.css and a userContent-example.css. Bug 1404398 for reintroducing the former; I don't see one for the latter.
It turns out that we anticipated this, I fixed it, but the patch got backed out.
https://reviewboard.mozilla.org/r/193442/diff/7#index_header
Whiteboard: sb+
I'm duping this to bug 1386404 which will now hopefully stick.

You still can't link to things in arbitrary locations, but the /chrome dir will work.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
(In reply to Gian-Carlo Pascutto [:gcp] from comment #18)

> You still can't link to things in arbitrary locations

That's a good thing I believe, it actually might be better if other partitions in Windows are restricted as well.
I have my images in (an arbitrary location in) D:/ and Windows and Firefox installed in C:/ and they work. That's the reason I didn't notice the restriction in Windows actually at first.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: