Accessing /tmp from snaps?

snapcraft
1

I often use /tmp to save files I don’t need to keep or to transfer them between applications.

But it seems with snaps this doesn’t work, is there any way to access /tmp?
File dialogs show the contents of /tmp from such applications but I can’t seem to read or write any files in them.

I’m asking this both as a snap developer (where I might create a file in /tmp from a snap to be opened by applications outside the snap) and as a user (where I might create a file in /tmp and want to open it from a snap).

2

snaps use a per-app /tmp, there is no way to access the hosts /tmp directory easily to prevent snaps from stealing data of other running applications …

3

but what if an app needs to open a temporaty file with another app?

4

Then it should put temporary files somewhere else than /tmp . For example firefox uses ~/Downloads which may not be a perfect choice but shows the way.

5

Quick clarification: this is correct inasmuch as it relates to accessing the system’s /tmp and sharing access to the same space between snaps, but the /tmp that a given snap application can see is specific to the given snap, not the application. This is an important distinction, as snaps can include multiple applications. If each of those applications saw a different /tmp, they wouldn’t be able to share things between them. Thankfully that’s not the case-- every app within the same snap sees the same /tmp, so it’s possible to e.g. proxy to the PHP app’s unix socket in /tmp/sockets from the Apache app.

1 Like
6

https://forum.snapcraft.io/t/cannot-use-gimp-snap-as-rawtherapee-external-editor/12908/6?u=coeur-noir

What is the best chance then ?

7

Just a 0,02€ bet

sudo   mount   --bind   /something   /home/user/snap/somewhere

Roughly as in GiMP and thumbnails for .xcf files

?

8

You may set TMPDIR variable to redirect saving of files from /tmp to somewhere else. Not all apps respect it but most do.

9

Hi,

We are in 2023, we use Ubuntu 22.04.x, Thunderbird for email and would like to use Okular (from snap) but is not possible to open a pdf file directly. (save as first and open the pdf after is not a solution)

We got a /tmp error… I read many threads with this kind of problem. So what is the solution? I mean something pro out the box, not mounting stuff or whatever…

So this thread are 2 years old… but same problem in 2023. What is the solution?

Thanks

1 Like
10

did you file a bug against thunderbird ? seems it is not using xdg portals properly (or your desktop does not have them installed)

11

Hi, this is what i got in syslog when i try to open file direcly from Thunderbird (permission problem):

thunderbird.desktop[26420]: /usr/bin/env: «/tmp/pid-25297/test-file.pdf»: Permission non accordée

xdg stuffs are installed on my computer. No i didn’t fill bug in Thunderbird because i read everywhere that is a snap problem with sandboxing tmp folder. Snap can’t read the /tmp folder. Right?

12

well, see above, snaps all have their own /tmp folder so nothing can spy on data stored there, but the xdg portals are existing for exactly that use case and it seems thunderbird does either not use them at all or uses them wrongly.

13

Quick question - is that per-app /tmp in memory file system or some real location?

14

It’s a real location-- a subdirectory of the host’s /tmp.

1 Like
15

Thank you, searched under /tmp and found it.

16

… and for completeness … if /tmp is a tmpfs your snaps /tmp’s will then indeed live in ram too :wink:

2 Likes
17 
sauer@host:~$ yq '.' /tmp/file.yaml 
Error: open /tmp/file.yaml: no such file or directory
sauer@host:~$ ls -l /tmp/file.yaml
-rw-rw-r-- 1 sauer sauer 599 Jun  1 14:30 /tmp/file.yaml

So, what if I am a competent sysadmin who has audited the code for yq, reaching the assessment that there is no risk of this particular snap “stealing data from other applications”. Having a snap-local /tmp provides zero benefit in this case (as with several others), as the application doesn’t use /tmp to begin with - except on the friggin’ command line where I specified a file in /tmp which I want the snap-delivered app to process.

How do I override this unnecessary restriction on filesystem usage and allow a fully trusted binary to access the directory of my choosing?

Sure, I can change the behavior of everything on the system to use a different $TMPDIR just to accommodate the snapd developer’s whims, but that’s not how this works. There is already a system-wide temporary directory available which isn’t in users’ homedir. It’s worked just fine since The Open Group defined /tmp to exist for temporary files way back when they established the Single UNIX Standard decades ago. The Linux Filesystem Heirarchy Standard specifies that /tmp must be available for programs which require temporary files. These are not new standards by any stretch of the imagination.

I’m the sysadmin here, not snapd. So if I decree that /tmp on this system will never be used to store anything private or that it’s otherwise just fine for snaps to access files in /tmp, then I as the sysadmin should also be able to instruct snapd to allow users to access files which have been placed in /tmp. Simply reinstalling with --classic or --devmode isn’t enough. So what is? There must be a way to change an arbitrary directory name.

18

That - yq - would make a good case for a classic Snap, where I believe this restriction doesn’t exist (someone correct me if I’m wrong). I believe classic would be granted for such tool from store reviewers.

19

I do understand risks and still want to have ability to explicitly allow access of snapped apps to system /tmp. Because without this I simply cannot edit my screenshots in any editor of your wide choice in snaps as those are stored in /tmp

20

Today I faced new limitation on temp directory. rclone installed from snap was refuses to connect simple ssh/sftp endpoint with ssh agent because… ssh agent socket is in /tmp.

I just new to this system BUT THIS BUG i seeing the second time in a row. I can only imagine how many other bugs are there and how often people struggle with your software.