According to FHS-3.0, /tmp
is for temporary files and /run
is for run-time variable data. Data in /run
must be deleted at next boot, which is not required for /tmp
, but still programs must not assume that the data in /tmp
will be available at the next program start. All this seems quite similar to me.
So, what is the difference between the two? By which criterion should a program decide whether to put temporary data into /tmp
or into /run
?
According to the FHS:
Programs may have a subdirectory of
/run
; this is encouraged for
programs that use more than one run-time file.
This indicates that the distinction between "system programs" and "ordinary programs" is not a criterion, neither is the lifetime of the program (like, long-running vs. short-running process).
Although the following rationale is not given in the FHS, /run
was introduced to overcome the problem that /var
was mounted too late such that dirty tricks were needed to make /var/run
available early enough. However, now with /run
being introduced, and given its description in the FHS, there does not seem to be a clear reason to have both /run
and /tmp
.
Best Answer
No reason to have both /run and /tmp
I think you're right.
/tmp
is essentially deprecated now we have/run
. If your program is in a position to do so (which requires that it was installed as a privileged operation), then nowadays you would use a sub-directory of/run
. This is for security reasons.E.g. the CUPS printing daemon does not run as root, but is generally installed from an OS package. The package installs
/usr/lib/tmpfiles.d/cups.conf
, andsystemd-tmpfiles
creates a directory it can access. Since the directory is under/run
, the name cannot have been maliciously claimed by an unprivileged user, unlike/tmp
which is world-writable."Unprivileged programs" which can't use
/run
directlyThe real distinction is if your program is being run by an arbitrary unprivileged user, under their own user ID. But you still generally don't want to use
/tmp
, because it can be accessed by other unprivileged users. You would prefer to use$XDG_RUNTIME_DIR
. Typically this is implemented as/run/user/$(id -u)
- so it happens to be a subdirectory of/run
as well. The location isn't guaranteed though; programs should always use the environment variable./tmp
would only be useful for ad-hoc co-operation between different unprivileged users on the system. Such ad-hoc systems are vulnerable to a malicious user refusing to co-operate and spoiling things for everyone :). One example would be unprivileged users deciding to run a version of thetalk
daemon, using a unix socket.Original information from Lennart Poettering
Note, Poettering's checklist below claimed that
/tmp
would be useful for "small files", whereas/run
should only be used for "communication primitives". I don't think this distinction is true either. The poster-boy for/run
isudev
, and I'm pretty sure/run/udev
includes internal databases . Once you have a/run
directory, I don't think anyone wants to follow the claimed distinction and create another directory, to clutter/tmp
. So in practice we just use/run
nowadays....
...
...
...
We kind of get away with the legacyI misread/tmp
socket used by the X window system, as described above.tmpfiles.d/x11.conf
. Looks more like it relies on co-operation :). I assume the code's been audited, such that denial of service is the worst that can happen.