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

[Juha Aatrokoski]

What @bluca says is mostly true and valid. But it is how things should
be, not how things actually are, and getting from the latter to the
former is easier said than done. E.g. with Xorg it *might* be
straightforward to fix the server and simple clients (i.e. those that
just call XOpenDisplay). But some clients may wish to do something
"fancier", and then there are tools and utilities that may not actually
open the display; those all will still expect to find the files under
/tmp/.

WRT first at boot vs. replaced later: not quite the same. Programs can
and do make sanity checks at startup, refusing to proceed if the
owner/permissions are wrong. Not many check at runtime with each usage
of the files. Also, this is precisely the purpose of
/usr/lib/tmpfiles.d/x11.conf: to ensure correct ownership and
permissions; too bad it does not also have rules to prevent removal of
the dirs/files.

The problem seems to be that in the olden days, /tmp *was* the (world-
writable) runtime directory, and that's why it was used as such e.g. by
X11 and that legacy practice still continues today (Filesystem Hierarchy
Standard v1.0 is from 1994; that is old, but not as old as X11).

Also had a thought: I don't know if it was actually codified in any way,
but dotfiles directly under /tmp and /var/tmp *may* have been de-facto
protected from runtime removal. Either explicitly, or because the
cleanup tools (of the time) just did globs of /tmp/* and /var/tmp/* for
removal candidates. Adding a tmpfiles rule that achieves this protection
might be worth consideration.

-- 
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:
  Confirmed
Status in xorg package in Ubuntu:
  Confirmed

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