mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #2685] Firefox 66: can't save downloaded files due to unwriteable /tmp/user/$UID #1691
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1691
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @chrsmrtnx on GitHub (May 9, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2685
Originally assigned to: @smitsohu on GitHub.
Running Debian buster with Firefox 66 and firejail 0.9.58.2, I found that with firejail's default Firefox profile, I couldn't download files. When clicking on a link to a file in Firefox, I'd get an error that the file "could not be saved, because you cannot change the contents of that folder. Change the folder properties and try again, or try saving in a different location".
To solve the problem, I had to comment out "private-tmp" in firefox-common.profile or, alternatively, add the line "whitelist /tmp/user/1000" (1000 being the relevant userid).
I suspect that the problem is that Firefox wants to write the downloaded file to /tmp/user/$UID before it moves it to the final download folder, typically under $HOME. But it can't because /tmp/user/$UID is read-only when "private-tmp" is set, unless you explicitly whitelist /tmp/user/1000 or whatever. (If I run "firejail --profile=firefox /bin/bash", I can't write to /tmp/user/1000: "touch /tmp/user/1000/foo" fails, whereas of course it works fine outside of firejail.)
Thanks.
@Vincent43 commented on GitHub (May 10, 2019):
Do you use pam-tmpdir?
@chiraag-nataraj commented on GitHub (May 10, 2019):
Btw, one way to solve this is to right-click and hit "Save As...", which (I think) should work? I actually opened a related bug here.
@chrsmrtnx commented on GitHub (May 11, 2019):
Yes, I do have libpam-tmpdir installed.
@chrsmrtnx commented on GitHub (May 11, 2019):
I tested this, and it does work, oddly. But then clicking on a link to a file still fails as described before. Odd.
@rusty-snake commented on GitHub (May 11, 2019):
@chrsmrtnx you can make this as an default. about:preferences -> always ask when downloading files (not sure about the correct english name) (
browser.download.useDownloadDir = false)@chrsmrtnx commented on GitHub (May 12, 2019):
Thanks - that's already the setting I was running with.
The error dialog ("could not be saved, because" etc.) pops up even before you get the dialog box that permits you to select the download folder.
@SkewedZeppelin commented on GitHub (May 12, 2019):
If we want to be "dirty" we can include a vendor.js override for Firefox that enables that option by default.
Just add
pref("browser.download.useDownloadDir", false);to
/usr/lib64/firefox/browser/defaults/preferences/firejail-fixes.jsor I think
/etc/firefox/pref/firejail-fixes.js@Vincent43 commented on GitHub (May 12, 2019):
I think that's too intrusive and doesn't really work as posted above.
@chiraag-nataraj commented on GitHub (May 19, 2019):
Yup, not entirely sure what's going on with Firefox. The bug I linked to kind of just...died, which is unfortunate.
Yup, this happens before you're ever prompted for where to save the file to.
If we have a
$UIDvariable that we can use in profiles, it might be worth it to whitelist/tmp/user/$UIDby default...?@Vincent43 commented on GitHub (May 20, 2019):
/tmp/user/$UIDshouldn't exist whenprivate-tmpis used. From where does it come from?@chiraag-nataraj commented on GitHub (May 20, 2019):
It's created within the sandbox because of
libpam-tmpdir.@Vincent43 commented on GitHub (May 20, 2019):
Isn't
libpam-tmpdircreating it only during login? How it can create it infirejail --private-tmpsandbox where/tmpis mount as new tmpfs filesystem?@chiraag-nataraj commented on GitHub (May 20, 2019):
You're right. Maybe it's because the temporary directory variables are exported, so firefox automatically creates the necessary parent directory?
@Vincent43 commented on GitHub (May 21, 2019):
That's possible but why
/tmp/user/$UIDwould be read-only then?@chiraag-nataraj commented on GitHub (May 21, 2019):
I'm not really sure, to be honest. But I know I've run into this when I whitelisted a subdirectory of
/tmp/user/$UID, which does make sense.Yeah, I'm not really sure what exactly is going on here, just that I've run into this in the past in other contexts. Somehow, I'm totally okay running with
private-tmp(and I see the weirdTemp-<blah>stuff in the sandbox), so I'm not quite sure what's going on here. My profile is quite a bit more restrictive (includingprivate-binandprivate-libinvocations as well as a whitelisting profile), which might inadvertently be helping here?@chrsmrtnx If I run
firejail --profile=/etc/firejail/firefox.profile bashand domkdir -p /tmp/user/1000/ && touch /tmp/user/1000/test, it works just fine (I had to use the full path to the profile because I have my own profiles in~/.config/firejailwhich it would have found otherwise).@chrsmrtnx commented on GitHub (May 21, 2019):
Interestingly, if I run
firejail --profile=/etc/firejail/firefox.profile bash, then I find that the directory/tmp/user/1000already exists; it contains a single file, namely,xauth-1000-_0.ls -al /tmp/user/yieldsdrwxr-xr-x 2 root rootetc.;touch /tmp/user/1000/testthen of course fails.@Vincent43 commented on GitHub (May 22, 2019):
firejail --profile=/etc/firejail/firefox.profile bashdoesn't create/tmp/user/$UIDon ubuntu withlibpam-tmpdirin my testing. You have to find what creates it on your system.@chiraag-nataraj commented on GitHub (May 22, 2019):
It doesn't on my system either, with the profile I use (custom hardened profile). I suspect
firefoxis the one creating the directory.[edit] Never mind, looking at @chrsmrtnx's reply, it seems that something else is creating the directory on their system...
@chrsmrtnx commented on GitHub (May 25, 2019):
I've noticed that on my KDE desktop,
$XAUTHORITYis set to/tmp/user/1000/xauth-1000-_0; apparently this is a KDE peculiarity (googling around yields lots of discussion). If I then runfirejail --profile=/etc/firejail/firefox.profile bash, I find that I have a root-only-writable/tmp/user/1000directory containingxauth-1000-_0, just as I've described above. Firefox then tries and fails to write the downloaded file to$TMP, which is/tmp/user/1000- again, as described above.But if, before running firejail, I set
$XAUTHORITYto$HOME/.Xauthority, then the problem with firefox vanishes. Immediately after runningfirejail --profile=/etc/firejail/firefox.profile bash, there is no/tmp/user/1000directory at all - just/tmp. The/tmp/user/1000directory only appears when I run firefox, but instead of being writable only by root, it's writable by the user, and so downloading files works fine.Another way to sidestep the problem is simply to set
$TMPto/tmpbefore running firejail/firefox.Based on all this, would I be correct in surmising that it's actually firejail that's creating the
/tmp/user/1000directory, based on$XAUTHORITY, in an attempt to setup a working environment? If so, one solution might just be to ensure that whatever$XAUTHORITYis set to, firejail makes sure the resulting path is user-writable.@chiraag-nataraj commented on GitHub (May 28, 2019):
@chrsmrtnx, ah, that would explain it (I'm running AwesomeWM myself, so I clearly wouldn't have this issue).
Hmm, yeah, that might be useful...I'm just worried about any security implications. @netblue30 or others, thoughts?
@smitsohu commented on GitHub (May 28, 2019):
I can give it a stab.
@smitsohu commented on GitHub (May 28, 2019):
The problem is here:
286b270778/src/firejail/fs_whitelist.c (L246)We just have to improve the way the path for the mount target is created.
@smitsohu commented on GitHub (Jul 27, 2019):
Thanks for this bug! It should be working now in master.
@chrsmrtnx commented on GitHub (Jul 28, 2019):
Pasting that snippet into 0.9.60 fixes the problem here. Many thanks.