Skip to main content
Commonmark migration
Source Link

Here's a rough guide how we suggest you (a Linux application developer) pick the right directory to use:

 
  1. You need a place to put your socket (or other communication primitive) and your code runs privileged: use a subdirectory beneath /run. (Or beneath /var/run for extra compatibility.)
  2. You need a place to put your socket (or other communication primitive) and your code runs unprivileged: use a subdirectory beneath $XDG_RUNTIME_DIR.
  3. You need a place to put your larger downloads and downloads in progress and run unprivileged: use $XDG_DOWNLOAD_DIR.
  4. You need a place to put cache files which should be persistent and run unprivileged: use $XDG_CACHE_HOME.
  5. Nothing of the above applies and you need to place a small file that needs no persistency: use $TMPDIR with a fallback on /tmp. And use mkstemp(), and mkdtemp() and nothing homegrown.
  6. Otherwise use $TMPDIR with a fallback on /var/tmp. Also use mkstemp()/mkdtemp().
 

Note that these rules above are only suggested by us. These rules take into account everything we know about this topic and avoid problems with current and future distributions, as far as we can see them. Please consider updating your projects to follow these rules, and keep them in mind if you write new code.

 

One thing we'd like to stress is that /tmp and /var/tmp more often than not are actually not the right choice for your usecase. There are valid uses of these directories, but quite often another directory might actually be the better place. So, be careful, consider the other options, but if you do go for /tmp or /var/tmp then at least make sure to use mkstemp()/mkdtemp().

Here's a rough guide how we suggest you (a Linux application developer) pick the right directory to use:

 
  1. You need a place to put your socket (or other communication primitive) and your code runs privileged: use a subdirectory beneath /run. (Or beneath /var/run for extra compatibility.)
  2. You need a place to put your socket (or other communication primitive) and your code runs unprivileged: use a subdirectory beneath $XDG_RUNTIME_DIR.
  3. You need a place to put your larger downloads and downloads in progress and run unprivileged: use $XDG_DOWNLOAD_DIR.
  4. You need a place to put cache files which should be persistent and run unprivileged: use $XDG_CACHE_HOME.
  5. Nothing of the above applies and you need to place a small file that needs no persistency: use $TMPDIR with a fallback on /tmp. And use mkstemp(), and mkdtemp() and nothing homegrown.
  6. Otherwise use $TMPDIR with a fallback on /var/tmp. Also use mkstemp()/mkdtemp().
 

Note that these rules above are only suggested by us. These rules take into account everything we know about this topic and avoid problems with current and future distributions, as far as we can see them. Please consider updating your projects to follow these rules, and keep them in mind if you write new code.

 

One thing we'd like to stress is that /tmp and /var/tmp more often than not are actually not the right choice for your usecase. There are valid uses of these directories, but quite often another directory might actually be the better place. So, be careful, consider the other options, but if you do go for /tmp or /var/tmp then at least make sure to use mkstemp()/mkdtemp().

Here's a rough guide how we suggest you (a Linux application developer) pick the right directory to use:

  1. You need a place to put your socket (or other communication primitive) and your code runs privileged: use a subdirectory beneath /run. (Or beneath /var/run for extra compatibility.)
  2. You need a place to put your socket (or other communication primitive) and your code runs unprivileged: use a subdirectory beneath $XDG_RUNTIME_DIR.
  3. You need a place to put your larger downloads and downloads in progress and run unprivileged: use $XDG_DOWNLOAD_DIR.
  4. You need a place to put cache files which should be persistent and run unprivileged: use $XDG_CACHE_HOME.
  5. Nothing of the above applies and you need to place a small file that needs no persistency: use $TMPDIR with a fallback on /tmp. And use mkstemp(), and mkdtemp() and nothing homegrown.
  6. Otherwise use $TMPDIR with a fallback on /var/tmp. Also use mkstemp()/mkdtemp().

Note that these rules above are only suggested by us. These rules take into account everything we know about this topic and avoid problems with current and future distributions, as far as we can see them. Please consider updating your projects to follow these rules, and keep them in mind if you write new code.

One thing we'd like to stress is that /tmp and /var/tmp more often than not are actually not the right choice for your usecase. There are valid uses of these directories, but quite often another directory might actually be the better place. So, be careful, consider the other options, but if you do go for /tmp or /var/tmp then at least make sure to use mkstemp()/mkdtemp().

deleted 54 characters in body
Source Link
sourcejedi
  • 53.6k
  • 23
  • 179
  • 337

We kind of get away with the legacyWe kind of get away with the legacy /tmp socket used by the X window system, as described above. I misread tmpfiles.d/tmpx11.conf socket used by the X window system, as described above. It's generally not desired to install the X server Looks more like it relies on a system that's already running, and accepting requests from unprivileged usersco-operation :). The implication I assume the code's been audited, such that denial of service is the worst that in this case, you could always schedule a reboot to avoid any funny businesscan happen.

We kind of get away with the legacy /tmp socket used by the X window system, as described above. It's generally not desired to install the X server on a system that's already running, and accepting requests from unprivileged users. The implication is that in this case, you could always schedule a reboot to avoid any funny business.

We kind of get away with the legacy /tmp socket used by the X window system, as described above. I misread 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.

added 776 characters in body
Source Link
sourcejedi
  • 53.6k
  • 23
  • 179
  • 337

No reason to have both /run and /tmp

"Unprivileged programs" which can't use /run directly

The real distinction is if your program is being run by anyan 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.

Original information from Lennart Poettering

TheNote, Poettering's checklist cited below claimsclaimed 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 is udev, 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.

Suggestions from Lennart Poettering

The real distinction is if your program is being run by any 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.

The checklist cited below claims 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 is udev, 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.

Suggestions from Lennart Poettering

No reason to have both /run and /tmp

"Unprivileged programs" which can't use /run directly

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

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 is udev, 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.

added 776 characters in body
Source Link
sourcejedi
  • 53.6k
  • 23
  • 179
  • 337
Loading
added 776 characters in body
Source Link
sourcejedi
  • 53.6k
  • 23
  • 179
  • 337
Loading
added 776 characters in body
Source Link
sourcejedi
  • 53.6k
  • 23
  • 179
  • 337
Loading
added 776 characters in body
Source Link
sourcejedi
  • 53.6k
  • 23
  • 179
  • 337
Loading
added 776 characters in body
Source Link
sourcejedi
  • 53.6k
  • 23
  • 179
  • 337
Loading
Source Link
sourcejedi
  • 53.6k
  • 23
  • 179
  • 337
Loading