Firejail: Firefox 66: can't save downloaded files due to unwriteable /tmp/user/$UID

[chrsmrtnx]

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]

Do you use pam-tmpdir?

[chiraag-nataraj]

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]

Do you use pam-tmpdir?

Yes, I do have libpam-tmpdir installed.

[chrsmrtnx]

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.

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]

@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]

@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)

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]

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.js
or I think
/etc/firefox/pref/firejail-fixes.js

[Vincent43]

I think that's too intrusive and doesn't really work as posted above.

[chiraag-nataraj]

I tested this, and it does work, oddly. But then clicking on a link to a file still fails as described before. Odd.

Yup, not _entirely_ sure what's going on with Firefox. The bug I linked to kind of just...died, which is unfortunate.

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.

Yup, this happens before you're ever prompted for where to save the file to.

If we have a $UID variable that we can use in profiles, it might be worth it to whitelist /tmp/user/$UID by default...?

[Vincent43]

because /tmp/user/$UID is read-only when "private-tmp" is set,

/tmp/user/$UID shouldn't exist when private-tmp is used. From where does it come from?

[chiraag-nataraj]

It's created within the sandbox because of libpam-tmpdir.

[Vincent43]

Isn't libpam-tmpdir creating it only during login? How it can create it in firejail --private-tmp sandbox where /tmp is mount as new tmpfs filesystem?

[chiraag-nataraj]

You're right. Maybe it's because the temporary directory variables are exported, so firefox automatically creates the necessary parent directory?

[Vincent43]

That's possible but why /tmp/user/$UID would be read-only then?

[chiraag-nataraj]

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 weird Temp-<blah> stuff in the sandbox), so I'm not quite sure what's going on here. My profile _is_ quite a bit more restrictive (including private-bin and private-lib invocations as well as a whitelisting profile), which might inadvertently be helping here?

@chrsmrtnx If I run firejail --profile=/etc/firejail/firefox.profile bash and do mkdir -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/firejail which it would have found otherwise).

[chrsmrtnx]

Interestingly, if I run firejail --profile=/etc/firejail/firefox.profile bash, then I find that the directory /tmp/user/1000 already exists; it contains a single file, namely, xauth-1000-_0.

ls -al /tmp/user/ yields drwxr-xr-x 2 root root etc.; touch /tmp/user/1000/test then of course fails.

[Vincent43]

firejail --profile=/etc/firejail/firefox.profile bash doesn't create /tmp/user/$UID on ubuntu with libpam-tmpdir in my testing. You have to find what creates it on your system.

[chiraag-nataraj]

It doesn't on my system either, with the profile I use (custom hardened profile). I suspect firefox is 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]

I've noticed that on my KDE desktop, $XAUTHORITY is set to /tmp/user/1000/xauth-1000-_0; apparently this is a KDE peculiarity (googling around yields lots of discussion). If I then run firejail --profile=/etc/firejail/firefox.profile bash, I find that I have a root-only-writable /tmp/user/1000 directory containing xauth-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 $XAUTHORITY to $HOME/.Xauthority, then the problem with firefox vanishes. Immediately after running firejail --profile=/etc/firejail/firefox.profile bash, there is no /tmp/user/1000 directory at all - just /tmp. The /tmp/user/1000 directory 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 $TMP to /tmp before running firejail/firefox.

Based on all this, would I be correct in surmising that it's actually firejail that's creating the /tmp/user/1000 directory, based on $XAUTHORITY, in an attempt to setup a working environment? If so, one solution might just be to ensure that whatever $XAUTHORITY is set to, firejail makes sure the resulting path is user-writable.

[chiraag-nataraj]

@chrsmrtnx, _ah_, that would explain it (I'm running AwesomeWM myself, so I clearly wouldn't have this issue).

Based on all this, would I be correct in surmising that it's actually firejail that's creating the /tmp/user/1000 directory, based on $XAUTHORITY, in an attempt to setup a working environment? If so, one solution might just be to ensure that whatever $XAUTHORITY is set to, firejail makes sure the resulting path is user-writable.

Hmm, yeah, that might be useful...I'm just worried about any security implications. @netblue30 or others, thoughts?

[smitsohu]

I can give it a stab.

[smitsohu]

The problem is here:
https://github.com/netblue30/firejail/blob/286b2707785abc1c75afc8bb82d956c60c561057/src/firejail/fs_whitelist.c#L246

We just have to improve the way the path for the mount target is created.

[smitsohu]

Thanks for this bug! It should be working now in master.

[chrsmrtnx]

Pasting that snippet into 0.9.60 fixes the problem here. Many thanks.