Open Bug 1505868 Opened 1 year ago Updated 1 month ago

userContent.css not applied to webpages when chrome folder is a symlink


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

63 Branch





(Reporter: rgant, Unassigned)



(1 file)

Attached image bugreport.png
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

In my Firefox profile I have symlinked my chrome folder to a folder in a git repo.

While my style rules for the monospace font in the signonsTree treechildren is applied, the CSS meant to apply to webpages does not apply.

Actual results:

Specifically this rule is applied: 
#signonsTree treechildren { font-family: monospace; }

This rule is not applied:
 a[href^="javascript:"] { cursor: crosshair; }

If I replace the symlink with the actual folder, then all the styles apply.

To test I added some CSS to userContent.css and took screenshots with and without a symlink that I attached.
body {
    background-color: green !important;
    color: red !important;

Expected results:

I expect a symlink not to affect how userContent.css is applied to webpages.
Could be related to
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
rgant, can you confirm whether it's the sandbox that is preventing this from working?  Try temporarily adding this line to your profile's user.js file:

user_pref("security.sandbox.content.level", 2);

and restarting the browser.

Please don't forget to remove that line when you're done testing, since it reduces Firefox's security.
Flags: needinfo?(rgant)
When I added `user_pref("security.sandbox.content.level", 2);` to user.js and switched back to the symlinked chrome folder all the in page custom styles were applied. Things worked as I expected and the problem was resolved.
Flags: needinfo?(rgant)
Thanks for confirming.  Moving this to the Sandboxing component to triage.
Component: CSS Parsing and Computation → Security: Process Sandboxing
Thanks for the report. This occurs because the Mac content process sandbox doesn't allow content processes to read from arbitrary paths on the filesystem in order to make it more difficult for a compromised content process to access private information. Even though the sandbox policy allows access to the $PROFILE/chrome dir, following a symlink from an allowed directory to a non-allowed directory is blocked by the sandbox implementation and we haven't added any special-case code to allow this to work for $PROFILE/chrome.

In order to support the chrome dir being a symlink or any files within the chrome dir being a symlink, we would have to either 1) check for any symlinks and then resolve them before enabling the sandbox or 2) add support to get access to these files via the parent process. The Linux content sandbox is an entirely different implementation and treats symlinks differently and so the fix for bug 1384483 isn't applicable to Mac.

It would be nice to support this use case.
Priority: -- → P3

For what it’s worth, I’ve just encountered this bug in Mozilla’s build of Nightly 64.0.2 running on Debian GNU/Linux Stretch while finally trying to switch to multiprocess Firefox (i. e. after switching ‘browser.tabs.remote.autostart’ to ‘true’). For years a single userContent.css symlinked to multiple profiles has been working fine, only with multiprocess it fails.

Steps to reproduce:

$ echo 'body { text-align: justify; hyphens: auto; }' > /tmp/userContent.css
$ mkdir -p /tmp/moz-profile/chrome
$ ln -s /tmp/userContent.css /tmp/moz-profile/chrome/
$ firefox --new-instance --profile /tmp/moz-profile/ --jsconsole

Got an error:

LoadSheetSync failed with error 80520012 loading built-in stylesheet 'file:///tmp/moz-profile/chrome/userContent.css'

Ensured visually, that sheet indeed was not applied.

Now try:

$ echo 'user_pref("browser.tabs.remote.autostart", false);' > /tmp/moz-profile/user.js
$ firefox --new-instance --profile /tmp/moz-profile/ --jsconsole

No error, user stylesheet was applied.

So, somebody else might found it useful as another workaround.

(In reply to Dmitry Alexandrov from comment #6)

useful as another workaround.

Note however, that it has a great disadvantage: you will lose the ability to reload these user-stylesheets (userContent.css, userChrome.css) without restarting a whole Firefox [1].


You need to log in before you can comment on or make changes to this bug.