Mit systemd 256.1 wurde ein Bug gefixt, der unter bestimmten Umständen das Home-Verzeichnis eines Users löschen konnte. Der Bug betraf vorrangig Entwickler oder Enthusiasten, die systemd-homed und/oder systemd-tmpfiles einsetzen. Die Handhabung des Bugs gab eher in menschlicher Hinsicht zu denken als in technischer. Was war passiert?
Einige User hatten den Befehl systemd-tmpfiles --purge verwendet und dabei ihr /home ganz oder teilweise gelöscht. Selbst beim Lesen der Manpages zusystemd-tmpfiles und dessen Optionen war nicht so einfach ersichtlich, dass neben temporären Dateien auch das /home gelöscht wird. Der durchschnittliche Benutzer würde das mit systemd 256 eingeführte systemd-tmpfiles --purge vermutlich weder kennen noch nutzen. Allerdings kann der Befehl ohne weitere Warnungen insofern missverstanden werden, als dass er /var/tmp aufräumen würde.
Was macht systemd-tmpfiles?
Um zu verstehen, was hier passiert und warum ein /home von systemd-tmpfiles anstatt wie üblich als Teil der Dateisystemeinrichtung während der Partitionierungs- und Einbindungsschritte des Installationsprozesses erstellt wird, kann Folgendes helfen: Für Automatisierung, Container, VMs, Testumgebungen usw. erlaubt systemd–tmpfiles, auf deklarative Art zu beschreiben, welche Dateien und Verzeichnisse auf einem System existieren sollen und welche Attribute sie haben sollen.
Im richtigen Umfeld sinnvoll
In /usr/lib/tmpfiles.d liegt unter vielen anderen die Datei /home.conf, die systemd hilft, ein ganzes System mit nur einer /usr/-Partition und einer leeren Root-Partition (oder tmpfs) einzurichten. Sie wird verwendet, um /home/ zu einem Subvolume anstelle eines normalen Verzeichnisses bei Btrfs im Rahmen der Nutzung von systemd-homed zu machen. Für Entwickler und Freunde von statelss systems ist das eine sinnvolle Funktion. Ich habe kurz nach der Einführung 2020 einen Artikel über systemd-homed verfasst.
Liest man aber die Manpage, so kommt man zu dem Schluss, dass nur Dateien gelöscht werden, die von systemd-tmpfiles erstellt wurden. Laut dem Bugreport wurde aber versucht, ein normales Home-Verzeichnis zu entfernen. Der User, dessen Bugreport dies beschrieb, wurde von Entwickler Luca Boccassi zunächst arrogant und rüde abgekanzelt:
So an option that is literally documented as saying “all files and directories created by a tmpfiles.d/ entry will be deleted”, that you knew nothing about, sounded like a “good idea”? Did you even go and look what tmpfiles.d entries you had beforehand?
Maybe don’t just run random commands that you know nothing about, while ignoring what the documentation tells you? Just a thought eh
https://github.com/systemd/systemd/issues/33349#issuecomment-2168794281
Bugfix in 256.1
Lennart Poettering war allerdings der Meinung, dass dies ein Fehler sei, der behoben werden müsse. Mit systemd 256.1 müssen zum Befehl systemd-tmpfiles --purge ein oder mehrere Verzeichnisse angegeben werden. Ohne dem macht der Befehl nichts mehr. Auch die Dokumentation wurde entsprechend angepasst. Soweit alles gut. Bleibt nur die Frage, warum es immer wieder Entwickler gibt, die glauben, Sie seien besser als die Anwender, die ihre Software benutzen.
So ganz habe ich die Zusammenhänge in der gegebenen Zeit, die ich zur Recherche hatte, noch nicht begriffen. Wie kommt systemd dazu, ein /home löschen zu wollen, das nicht von systemd-tmpfiles erstellt wurde. In der Manpage steht jedenfalls: If this option is passed, all files and directories created by a tmpfiles.d/ entry will be deleted. Vielleicht kann mich ja jemand diesbezüglich aufklären.
