I am bumping this issue since it is something I use(d) frequently: I have different emails with Libreoffice related attachments and I need to explicitly save them somewhere to read them, since Libreoffice is confined
The issue has been reported again: bug #1790608.
We really need to devise a solution that doesn’t involve changing thunderbird/libreoffice.
How does one change that particular TMP variable? Are there any down sides to doing this?
Is this related and does it offer any hope?
Isn’t there a
TMPDIR environmental variable?
Yes, but that won’t help because you can’t set
$TMPDIR to point to somewhere outside the confinement of the snap.
Is it possible to expose host’s
/tmp/mozilla_$USER$N to Mozilla snaps via Apparmor rules?
It is the mount namespace that is the problem, not AppArmor. Firefox is saving files to /tmp, which is /tmp only in its runtime mount namespace. libreoffice and the system have different /tmp than firefox.
Why not? I don’t know if this works, but in the firefox wrapper you could set:
FFTMP="$HOME/Downloads/firefox-tmp" if [ ! -e "$FFTMP" ]; then mkdir -p "$FFTMP" || FFTMP="/tmp" fi export TMPDIR="$FFTMP" firefox
Firefox plugs the ‘home’ interface and so if it is connected it is able to create the temporary directory in ~/Downloads, otherwise it uses /tmp like normal. ~/Downloads is from the host and not snap-specific, so it can now write there, and any application plugging the home interface can get to those files (eg, libreoffice).
Thanks @jdstrand, that looks like a decent workaround to the problem at hand when the two apps involved are snaps. It won’t work in the case of bug #1790608 where the app writing to /tmp is packaged as a deb, unless the user has explicitly set
$HOME/Downloads/thunderbird-tmp and ensured that this folder exists. And this doesn’t handle localization of the name of the
Downloads folder. Also, this negates the temporary nature of
/tmp, which typically isn’t preserved across reboots.
Beeing obliged to let cache/temporary files in the user home may become a problem.
I am using btrfs for 3 years now and have organized my disk in subvolumes, as btrfs allow it, to move these dirs (cache/temp) away from user home.
FYI subvolumes in btrfs/zfs is between a partition and a directory: every files in a subvol is isolated like in a partition.
btrfs tools allow you to backup quickly subvols (faster that rsync) and send backups over ssh, or elsewhere.
I have voluntarily removed the cache and temporary files of all kinds from my home to put them in a separate sub-volume, which is not backed up when we save home / users directories, and this for reasons of cost of storage and speed of backup.
user home and cache user dirs are encrypted with ecryptfs , and cache is mounted in ~/Cache/.
/cache/gaetanquentin-perso on /home/gaetanquentin-perso/Cache type ecryptfs (rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=1c3d846bedc670f4,ecryptfs_sig=8f85385bf3c6e37b,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
in user home , some dirs are linked to this mounted cache:
lrwxrwxrwx 1 gaetanquentin-perso gaetanquentin-perso 12 mars 1 2017 .cache -> Cache/.cache
drwxr-xr-x 1 gaetanquentin-perso gaetanquentin-perso 336 mars 1 2017 Cache
lrwxrwxrwx 1 gaetanquentin-perso gaetanquentin-perso 13 mars 1 2017 .recoll -> Cache/.recoll
Well, all that to say that i just realized that snap firefox complained about that, silently, since it is apparmor which is complaining:
Oct 18 18:52:54 gquentin-ssd-t3 kernel: [ 1276.095226] audit: type=1400 audit(1539881574.531:201): apparmor=“DENIED” operation=“open” profile=“snap.firefox.firefox” name="/cache/gaetanquentin-perso/ECRYPTFS_FNEK_ENCRYPTED.FWYQDMFfvQNkx-Qyfwlym5mcWjz1LB1V2fcC.00e2XcIPNeVfwOvkFKqKE–/ECRYPTFS_FNEK_ENCRYPTED.FWYQDMFfvQNkx-Qyfwlym5mcWjz1LB1V2fcCv2Lp7Rp06mtCNBDQIIXl5U–/ECRYPTFS_FNEK_ENCRYPTED.FYYQDMFfvQNkx-Qyfwlym5mcWjz1LB1V2fcCLkpmI.31U4iCoeY2hWpwKOvvhNC9S6UcO6vGaQ1hzKTZq2vl.30ehGwU1y1gvllk" pid=11146 comm=57656220436F6E74656E74 requested_mask=“wr” denied_mask=“wr” fsuid=1003 ouid=1003
Oct 18 18:52:54 gquentin-ssd-t3 kernel: [ 1276.096458] audit: type=1400 audit(1539881574.531:202): apparmor=“DENIED” operation=“open” profile=“snap.firefox.firefox” name="/cache/gaetanquentin-perso/ECRYPTFS_FNEK_ENCRYPTED.FWYQDMFfvQNkx-Qyfwlym5mcWjz1LB1V2fcC.00e2XcIPNeVfwOvkFKqKE–/ECRYPTFS_FNEK_ENCRYPTED.FWYQDMFfvQNkx-Qyfwlym5mcWjz1LB1V2fcCv2Lp7Rp06mtCNBDQIIXl5U–/ECRYPTFS_FNEK_ENCRYPTED.FYYQDMFfvQNkx-Qyfwlym5mcWjz1LB1V2fcCtu20f0PDfFagWlDPAVIdZBQHGmRGfWHFVXdPCu1aKsqqLw6f6PkGcPWnmIkQTJoR" pid=11146 comm=57656220436F6E74656E74
Does that mean that i cannot use these subvol any more?
that looks to me that it’s an issue with the way you’re using ecryptfs, not necessarily subvols. We might need to tweak the apparmor profiles for this, if we want to support it at all
I also have this issue. in that I cannot open a file directly from the snap version of Firefox in the snap version of Libre Office. The problem being Libre Office cannot access the /tmp location where Firefox places the file. Is this problem going to be fixed?
the confined /tmp is a security feature and will not be “fixed” as such … but the work on integrating XDG desktop portals is ongoing, once this is fully implemented sharing files transparently (whithout saving the file to your homedir first (like you have to do today), where both snaps have access) will be possible.
Thank you for your reply. I’m glad to hear that the functionality to open files directly from Firefox will be available, hopefully in the near future. It is this sort of behavior which puts off non-techies from using Ubuntu. Thanks again for your reply.
I understand the discussion here is now mainly about two programs running under the same user account trying to pass a temporary file from one to another. This could well be solved by the xdg-desktop-portal but what is the solution for programs that are in no way connected to desktop (and so don’t use D-Bus), run under different accounts (including one running inside the Snap confinement and another outside), and still want to exchange some data via /tmp (being the global and universally accessible location) like a lock file, or a UNIX domain socket, or whatever else?
/tmp isn’t “the global and universally accessible location” any more
Thanks for the discussion. My customer has just reported this problem after starting to use LibreOffice snap in daily work. I can probably devise a workaround based on this discussion for her.
So where should users store temporary files they want to open in a Snap-based app from now on? I really don’t want to be oblidged to delete these files manually, so /tmp was the perfect location.
I would personally never think about using Snap, but I was forced to by Ubuntu
Any news on this subject? I’m using Ubuntu 20.04 and the option of opening a file (temporarily downloaded) from Firefox 80 directly in LibreOffice 7 (snap) is still not working.