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