Firefox can't download files to an fscrypt protected, unlocked folder

[Piotr Kołaczkowski]

My Downloads folder is encrypted by fscrypt. I can save and read files in there. However, for Firefox - all downloads fail and it says only "download failed" and offers a button to retry which fails again. After a failed attempt, a file is created with a proper file name but no content (0 bytes).

When I changed the download dir to a different non-fscrypted folder, everything works properly and files do get properly saved.

I switched to Chromium and Chromium has no problems downloading files into any dirs, regardless encrypted or not.

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: firefox 62.0.3+build1-0ubuntu1
ProcVersionSignature: Ubuntu 4.18.0-8.9-generic 4.18.7
Uname: Linux 4.18.0-8-generic x86_64
AddonCompatCheckDisabled: False
ApportVersion: 2.20.10-0ubuntu11
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: pkolaczk 3692 F.... pulseaudio
 /dev/snd/pcmC0D0c: pkolaczk 3692 F...m pulseaudio
 /dev/snd/pcmC0D0p: pkolaczk 3692 F...m pulseaudio
BuildID: 20181002091723
Channel: Unavailable
CurrentDesktop: ubuntu:GNOME
Date: Mon Oct 8 12:10:57 2018
DistributionChannelDescriptor:
 # This is a distribution channel descriptor
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-somerville-xenial-amd64-20160624-2
Extensions: extensions.sqlite corrupt or missing
ForcedLayersAccel: False
IncompatibleExtensions: Unavailable (corrupt or non-existant compatibility.ini or extensions.sqlite)
InstallationDate: Installed on 2017-04-12 (543 days ago)
InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary 20160624-10:47
IpRoute:
 default via 192.168.0.1 dev enxd481d7358c11 proto dhcp metric 100
 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
 192.168.0.0/24 dev enxd481d7358c11 proto kernel scope link src 192.168.0.2 metric 100
 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Locales: extensions.sqlite corrupt or missing
Plugins: Shockwave Flash - /usr/lib/adobe-flashplugin/libflashplayer.so (adobe-flashplugin)
PrefSources: prefs.js
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=pl_PL.UTF-8
 SHELL=/bin/bash
Profiles: Profile0 (Default) - LastVersion=62.0.3/20181002091723
RelatedPackageVersions: adobe-flashplugin 1:20180911.1-0ubuntu0.18.04.1
RunningIncompatibleAddons: False
SourcePackage: firefox
Themes: extensions.sqlite corrupt or missing
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/24/2018
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.11.0
dmi.board.name: 06X96V
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.11.0:bd07/24/2018:svnDellInc.:pnPrecision5520:pvr:rvnDellInc.:rn06X96V:rvrA00:cvnDellInc.:ct10:cvr:
dmi.product.family: Precision
dmi.product.name: Precision 5520
dmi.product.sku: 07BF
dmi.sys.vendor: Dell Inc.

[Olivier Tilloy (osomon)]

That sounds like an upstream issue. Would you mind filing a bug report at https://bugzilla.mozilla.org/enter_bug.cgi#h=dupes%7CFirefox and sharing the link to it here?

Thanks!

[lodart (romainlebouc)]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

I encrypted my homedir (on Ubuntu 18.04) with fscrypt following this tutorial : https://tlbdk.github.io/ubuntu/2018/10/22/fscrypt.html
Then, I try to download any file from internet with Firefox in my Download folder, in my homedir (or any encrypted folder).

Actual results:

The download instantly breaks. Only a 0kb file appears with the correct name.

Expected results:

The file should be downloaded correctly.

[Manu Schwachsinn (manu-here)]

I can confirm this bug and will create a bug report on bugzilla :)

[Troels Liebe Bentsen (tlbdk)]

It seems Firefox downloads the file to a folder under /tmp and then tries to rename the file to the final location:

Rename operations to a fscrypt folder is not supported from an unencrypted folder, files have to be copied, so this results in an EPERM error code.

18290 rename("/tmp/mozilla_tlb0/FEekjG1c.xlsx.part", "/home/tlb/Downloads/test.xlsx" <unfinished ...>
18247 <... writev resumed> ) = 24
18256 <... futex resumed> ) = 0
18247 poll([{fd=4, events=POLLIN}], 1, -1 <unfinished ...>
18290 <... rename resumed> ) = -1 EPERM (Operation not permitted)

Bind mounting a non-encrypted folder to the same location gives an EXDEV error and Firefox seems to handle that case:

17870 rename("/tmp/mozilla_tlb0/IwoS6IQp.xlsx.part", "/home/tlb/Downloads/test.xlsx" <unfinished ...>
17973 write(38, "\372", 1 <unfinished ...>
17906 <... madvise resumed> ) = 0
17973 <... write resumed> ) = 1
17870 <... rename resumed> ) = -1 EXDEV (Invalid cross-device link)

[Troels Liebe Bentsen (tlbdk)]

Don't really know if this is the right location:

https://github.com/mozilla/gecko-dev/blob/7ccc9d8b0bd9f879b6f24f15d8416493228697ac/xpcom/io/nsLocalFileUnix.cpp#L1002

[Troels Liebe Bentsen (tlbdk)]

The issue is because firefox does a rename from the /tmp folder to the encrypted home folder, right now fscrypt returns EPERM instead of EXDEV that would be normal when the operation can not complete because of crossing a mount point or in this case unencrypted to an encrypted folder.

The upstream firefox bug is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1521041

But one could argue that the kernel interface is broken and it should return EXDEV as tools like mv also breaks, there are some patches in the works but I don't know how far they are, maybe ubuntu could carry them until they go upstream:

https://patchwork.kernel.org/patch/9943001/

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to Troels Liebe Bentsen from comment #2)

> Don't really know if this is the right location:
>
> https://github.com/mozilla/gecko-dev/blob/7ccc9d8b0bd9f879b6f24f15d8416493228697ac/xpcom/io/nsLocalFileUnix.cpp#L1002

So I guess if there's a permission error we should also try copying? The thing is, it seems like permission errors might not necessarily imply that moves will fail but copies will work... OTOH maybe it's worth trying and we could still give up after the copy fails...

Triage suspects the downloads code is probably using OS.File, so moving there first, though it's possible that the XPCOM nsILocalFile unix implementation also needs changing.

[Troels Liebe Bentsen (tlbdk)]

There is also a bit of discussion on changing the behaviour of fscrypt to use EXDEV instead:

https://github.com/google/fscrypt/issues/124

But why is Firefox using the /tmp folder in the first place, would it not be better to do a tmp file in the same folder to start with and then maybe fall back to /tmp if that fails?

[Dteller-v (dteller-v)]

(In reply to Troels Liebe Bentsen from comment #4)

> There is also a bit of discussion on changing the behaviour of fscrypt to use EXDEV instead:
>
> https://github.com/google/fscrypt/issues/124
>
> But why is Firefox using the /tmp folder in the first place, would it not be better to do a tmp file in the same folder to start with and then maybe fall back to /tmp if that fails?

This would probably be better, yes. Both for privacy (if you're downloading to an encrypted folder, there is probably a good reason) and for performance (renaming across file systems is slow).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Chris A (c-arderne)]

Just adding this for others who are looking for help.
Following Troels' suggestion, this can be overcome with by binding /tmp/ to a directory in your home directory:

mkdir ~/.tmp
sudo mount -B ~/.tmp /tmp

[Chris A (c-arderne)]

Confirming that the patch described here [0] has fixed the issue (tested today running Ubuntu 19.04 with mainline kernel 5.1.3.

[0] https://github.com/google/fscrypt/issues/124

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

I'm hopeful this (ie the end-user-facing issue; we've not changed what temp dir is used) would be fixed on current nightlies ( https://nightly.mozilla.org/ ) based on bug 1555644 being fixed on Linux/macOS now. Would it be possible for you to verify if your issue is resolved on nightly?

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

If the previous fix didn't fix it, the new downloads changes that are shipping with 97 should have done. I'm going to resolve this wfm; if this is still broken with 97 or later, please reopen and provide more information.