Against /tmp

Original Article ↗ Hacker News Discussion ↗

Unix’s traditional `/tmp` directory—world-writable, shared, and often cleaned unpredictably—is being reevaluated as a security liability and source of subtle bugs. Commenters weigh the limited performance benefits of putting `/tmp` in RAM against risks like denial-of-service, TOCTOU vulnerabilities, and data leaks, and argue for per-user or per-service temporary directories via mechanisms like `$TMPDIR`, `pam_namespace`, systemd’s `PrivateTmp`, or XDG runtime paths. Many conclude that in an era of single-user desktops and containerized workloads, shared global temp space should be opt‑in rather than the default.

/tmp on tmpfs and performance

  • Several commenters like mounting /tmp as tmpfs (RAM-backed) for speed and automatic wipe on reboot.
  • Others note tmpfs pages can be swapped out under memory pressure, which partially defeats “RAM-only” expectations but improves overall system efficiency.
  • Risk: a too-small or too-large tmpfs can trigger OOM killer or deadlocks if /tmp fills; real-world examples include installers and tools (MATLAB, sox) failing or forcing reconfiguration.
  • Some argue that for many workloads, regular filesystems with page cache behave similarly to tmpfs, so performance gains are modest; tmpfs’s main advantage is ephemerality.

Security and correctness issues with shared /tmp

  • Core concern: /tmp is shared global mutable state crossing security boundaries, enabling attacks like TOCTOU races, denial of service via predictable filenames, and privilege escalation patterns.
  • Some see this as mostly relevant to classic multi-user systems; others argue untrusted applications on single-user machines are now the bigger risk and still benefit from isolation.
  • There is debate on how significant /tmp-driven breaches are in practice; one commenter explicitly asks for real statistics.

Per-user and namespaced temporary directories

  • Multiple approaches discussed:
    • Per-user directories via $TMPDIR, /tmp/$USER, $HOME/tmp, or /run/user/$UID / $XDG_RUNTIME_DIR.
    • PAM-based polyinstantiation (pam_namespace.so) to give each user an isolated /tmp.
    • systemd unit options like PrivateTmp= and DynamicUser= for per-service private /tmp.
  • Limitations: many mechanisms rely on PAM or systemd; environments like Kubernetes pods or FROM scratch images may lack /run/user/$UID or even /tmp by default.
  • Some prefer using /dev/shm or runtime directories for IPC rather than global /tmp.

Data loss, cleanup policies, and user habits

  • Several anecdotes of “valuable” work lost because it was stored in /tmp and cleaned on reboot; advice is to use $HOME/tmp or /var/tmp (though some systems also clean /var/tmp).
  • systemd’s tmpfiles.d is noted as providing age-based cleanup for /tmp and /var/tmp, but behavior is distro-dependent.
  • General recommendation: treat any “temporary” directory as subject to deletion at any time.

APIs, alternatives, and broader OS design

  • Some advocate using descriptor-based APIs (openat*, *at, O_TMPFILE) to avoid pathname races, though portability and discoverability can be issues.
  • Broader discussion contrasts POSIX user-based permissions with capability-style and mobile-style per-app sandboxes (iOS, Android, Flatpak, pledge/unveil), arguing that shared filesystems and /tmp are legacy compromises that don’t match modern threat models.