Now that I have had more time to ponder this issue, I realize that it is also a security vulnerability. And spurred by the realization, I vaguely recall coming across several articles in the past (some from before systemd was a thing) about how automatic runtime cleaning of /tmp and /var/tmp is (or can be) a security issue.
Firstly, an attacker (an unprivileged local user in this context) may be able to control what files are removed in the cleanup, though it may be possible to mitigate/prevent this by properly hardening the cleanup program. More importantly, when files or directories of long-running processes (that assume they still have full control over them) are removed in the cleanup, the attacker can hijack them by recreating them, thus possibly gaining read/write capabilities beyond their privileges. For example, replacing a file still used by a process (though obviously not for a while since it got cleaned) with a symlink, it may be possible to overwrite arbitrary system files. As a more specific example applicable to a current Ubuntu 24.04.1 setup, if an X server is not started for a month after system boot, /tmp/.X11-unix gets removed. The attacker can then create it, and as owner will be able to rename files it contains. So when an X server is later started, rename the socket X0 to X0-foo, create your own socket X0 and you will have MitM eavesdropping/tampering on another user's X display. ** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2088268 Title: systemd /tmp cleaning removes files that it shouldn't To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2088268/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
