Sharing files via /tmp

snapd
1

I am creating a new topic to continue a discussion that was started in another thread.

Excerpts:

I’m seeing the same problem when opening e-mail attachments from thunderbird with the libreoffice snap. Thunderbird saves a temporary copy of the attachment to the system-wide /tmp, and libreoffice fails to see it:

/tmp/mozilla_osomon0/test.odt doesn't exist

Should firefox and thunderbird be “fixed” to write files to some other place under $HOME instead of /tmp ?

Or as suggested by @jdstrand, would it be somehow possible to have the libreoffice snap (and others interested in that use case) see the system-wide /tmp ?

2

We probably don’t want that sort of off-the-hook communication between snaps as it becomes pretty much impossible to mediate. Who else will be opening that file besides libreoffice and mozilla?

The proper way to do that is to ask the application registered to open files of that type to have a look at that file, and only after the user has approved that interaction.

There’s some relevant discussion about this at the bottom of the xdg-open improvements topic.

Meanwhile, sharing via somewhere in $HOME may be the best way to go indeed.

3

That makes sense, but assuming the caller placed the file in the system-wide /tmp (or in its own confined /tmp), the receiving application still won’t be able to see it. Would the xdg-open wrapper grow some mechanism to make the file visible to the receiver?

4

I don’t really follow what Niemeyer is saying here, but this is an issue that needs fixing somehow, I just tried to open a Word document from a Facebook group using the LibreOffice snap (I’ve removed the Deb and just have that installed) and because I said ‘Open’ rather than ‘Save’, it error-ed out (attached below) and didn’t open the file. If we made the LibreOffice snap default one day and someone who isn’t technical ran into this bug, they would be very confused and annoyed indeed.

What steps are we going to take to resolve this issue? Do we somehow allow access to /tmp for opening files or do we have to apply a custom patchset to all applications that try saving to /tmp or what? :slight_smile:

As you can see, it’s even worse if someone ticks the ‘Do this automatically for files like this from now on’ button because then they really can’t see how to fix issue unless they work out what the problem is and Google the right stuff online to find the way to change the setting back. Very unlikely that a non-technical person would be able to do this.

Would’ve smudged those screenshots but I don’t have fast enough Internet to get GIMP really xD. The difference in file names is because I tried to open this multiple times but got the same error

2 Likes
5

We need to think about it some more. In general our policy is to not require applications to be changed for them to be used as a snap, so we’ll try to preserve that in this case as well. At the same time, this is a pretty unfortunate behavior from Firefox for several reasons, some of which may be better understood in this super long thread coming through many years: https://bugzilla.mozilla.org/show_bug.cgi?id=69938

Quick workarounds:

  • Save the file in $HOME/Downloads or similar, instead of trying to open it directly from /tmp
  • Change the location in the TMP environment variable with which Firefox runs
1 Like
6

It’s a great policy! :smiley:

Oh, Firefox uses an environment variable for that? Would be easiest if we snapped Firefox and got a scriptlet to do that, that wouldn’t involve changing Firefox itself at all (though it wouldn’t fix the bug for nearly all Firefox users)! :slight_smile:

7

Same problem with Thunderbird. Both workarounds from @niemeyer are not possible for me.
The first is not because I need to quick open the files, while saving them, open the folder and double click is a lot annoying.
The second is not because I should do it globally and it’s too much intrusive.

8

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

9

The issue has been reported again: bug #1790608.
We really need to devise a solution that doesn’t involve changing thunderbird/libreoffice.

10

How does one change that particular TMP variable? Are there any down sides to doing this?

11

Is this related and does it offer any hope?

12

Isn’t there a TMPDIR environmental variable?

13

Yes, but that won’t help because you can’t set $TMPDIR to point to somewhere outside the confinement of the snap.

1 Like
14

Is it possible to expose host’s /tmp/mozilla_$USER$N to Mozilla snaps via Apparmor rules?

15

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.

1 Like
16

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

2 Likes
17

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 $TMPDIR to $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.

18

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?

19

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 :slight_smile:

20

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?