[Bug 2088268] Re: systemd /tmp cleaning removes files that it shouldn't

[Luca Boccassi]

/tmp/ is world writable, so there is no guarantee that one process will
be the first to write to a file anyway. The case of "another process
replaced it after deletion" is the same as "another process got there
first on boot", and cannot be avoided. Anything using /tmp/ needs to be
aware of this, and only use safe and non-guessable subdirectories, for
example via mkdtemp, and need to use O_NOFOLLOW and friends when
opening, and so on and so forth.

Or just do not use /tmp/ for functionality-critical files, and use
RuntimeDirectory= instead which is managed correctly, without any hassle
for the program.

If any of the above is _really_ not possible, then such package needs to
ship a drop-in in /usr/lib/tmpfles.d/ instructing sd-tmpfiles to leave a
specific path or pattern alone.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2088268

Title:
  systemd /tmp cleaning removes files that it shouldn't

Status in systemd package in Ubuntu:
  New
Status in xorg package in Ubuntu:
  New

Bug description:
  On Ubuntu 24.04.1, systemd 255.4-1ubuntu8.4, the fix for bug #2019026
  causes files under /tmp to be removed if their age is greater than 30
  days. However, there are files under /tmp that should not be removed
  at runtime regardless of their age (whether they belong in that
  directory at all is a separate question), for example those listed in
  /usr/lib/tmpfiles.d/x11.conf (I have witnessed the disappearance of
  X11 lock files, though the sockets are still there; /tmp/.XIM-unix and
  /tmp/.font-unix have also disappeared).

  I am not familiar enough with systemd-tmpfiles to figure out whether
  those files can be properly protected from removal with a tmpfiles.d
  configuration change, but I do know that the current configuration
  does not do that.

  I noticed this problem when a couple of TigerVNC sessions became
  inaccessible a month after starting them, which turned out to be
  because the "cached" password file in /tmp/tigervnc.XXXXXX/passwd was
  removed. This is at least partially a bug in tigervnc, but the problem
  also affects other critical not-to-be-removed-or-else files under
  /tmp.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2088268/+subscriptions