Closed Bug 1384483 Opened 7 years ago Closed 7 years ago

userContent.css gets blocked with sandbox level 3 on Linux

Categories

(Core :: Security: Process Sandboxing, defect)

56 Branch
x86_64
Linux
defect
Not set
trivial

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox57 --- fixed

People

(Reporter: u584781, Assigned: gcp)

Details

(Keywords: nightly-community, Whiteboard: sb+)

Attachments

(1 file)

STR:
- Open a page with CSS rules in $HOME/.mozilla/firefox/$profile/chrome/userContent.css.

AR:
- The CSS rules don't get applied.
- A message in the Browser Console that the access to the file produced error 80520015 (which seems to be NS_ERROR_FILE_ACCESS_DENIED).

ER:
- The CSS should get applied.

Additional notes:
- My chrome directory is a symbolic link to a git controlled directory outside the $HOME/.mozilla directory.

- I was able to prevent the block by adding the full path to the security.sandbox.content.read_path_whitelist pref.
I think we can add a whitelist rule for this by default. It's consistent with allowing read access to content theming data, and there's no risk of leaking sensitive data if we only whitelist the specific file.
Status: UNCONFIRMED → NEW
Component: Untriaged → Security: Process Sandboxing
Ever confirmed: true
Product: Firefox → Core
Whiteboard: sb?
(In reply to Plamen Kolev from comment #0)
> I was able to prevent the block by adding the full path to the
> security.sandbox.content.read_path_whitelist pref.

Confirming the bug, and precising the workaround, as it took me
a few tries to get it right. The pref is a comma-separated string
and file:// is unnecessary. So typically you'd set it to:
/home/USERNAME/.mozilla/firefox/PROFILENAME/chrome/userContent.css

Then, a browser restart is required.

Hope a fix arrives soon, thanks Plamen for the workaround 
I've added some documentation for those preferences to the Sandboxing wiki. But they should be unneeded - I'll have a fix for this up soon.
(In reply to Gian-Carlo Pascutto [:gcp] from comment #3)
> I've added some documentation for those preferences to the Sandboxing wiki.
> But they should be unneeded - I'll have a fix for this up soon.

One more data point that may be of interest for whoever works on this.
Whitelisting works more or less with symlinks (like Plamen in comment 0,
my chrome folder is a symlink to a folder outside $HOME/.mozilla):
 - Works if the whole chrome *folder* is a symlink
 - But fails if the chrome folder is a real directory and the
   userContent.css *file* is a symlink.
Maybe it's something worth addressing (or logging/warning about).
Whiteboard: sb? → sb+
Target Milestone: --- → mozilla56
(In reply to Ronan Jouchet from comment #4)
> (In reply to Gian-Carlo Pascutto [:gcp] from comment #3)
> > I've added some documentation for those preferences to the Sandboxing wiki.
> > But they should be unneeded - I'll have a fix for this up soon.
> 
> One more data point that may be of interest for whoever works on this.
> Whitelisting works more or less with symlinks (like Plamen in comment 0,
> my chrome folder is a symlink to a folder outside $HOME/.mozilla):
>  - Works if the whole chrome *folder* is a symlink
>  - But fails if the chrome folder is a real directory and the
>    userContent.css *file* is a symlink.
> Maybe it's something worth addressing (or logging/warning about).

Had the same problem, confirmed fixed with this solution.
Assignee: nobody → gpascutto
Comment on attachment 8892069 [details]
Bug 1384483 - Allow reading userContent.css in the sandbox. j?jld

https://reviewboard.mozilla.org/r/163086/#review168972

::: commit-message-748a8:1
(Diff revision 1)
> +Bug 1384483 - Allow reading userContent.css in the sandbox. j?jld

Typo: `j?` instead of `r?`, so I wasn't flagged for review.
Attachment #8892069 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/29fd2ffa843b
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: