Systemd Logo

Mit systemd 256 kann versehentlich das Home-Verzeichnis gelöscht werden

News 17 Kommentare

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.

Die Manpage zu tmpfiles.d ist länger als mein arm und fängt so an

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.

Teilt den Beitrag, falls ihr mögt

17 Kommentare

  1. Ich wollte ja nicht in dem Ton antworten.
    Aber wenn der Entwickler selbst das auch kann, dann darf ich das auch:
    Die Programmierung ist einfach Murks.

    Er fühlte sich wohl angegriffen.
    Denn “Getroffene Hunde bellen”.

    Bei mir kommt allerdings noch hinzu, dass ich das Krebsgeschwür nicht mag. Es sich aber, wie eben leider Krebs ist, sich immer weiter ausbreitet und alles zu verschlingen versucht.
    Aber hey. Ist ja alles so einfach. Das ist leider die heutige Zeit. Da stimme ich Ralf 100% zu.
    Auch dem Rest in seinem ersten Kommentar.

    8

  2. “Ich habe auf #debian-next darüber gesprochen und es scheint, dass dies kein Fehler ist, sondern eine Funktion, da systemd-tmpfiles auch das automatische Erstellen von Datenverzeichnissen wie /home bearbeitet und die –purge Flag soll sie sauber löschen”

    Naja da macht systemd schon wieder etwas, was ein init-system garnichts an geht und es auch gefaehrlich fuer das ganze system macht.

    I’m glad I’m not running systemd.

    13

    2. 1.) systemd ist kein init-system. Es war auch nie alleinig als solches geplant. Es erfüllt als erste Aufgabe den Init. Selbst in der ersten Zeit tat es aber bereits mehr.
      2.) Ich habe die Diskussion auf #debian-next gesehen
      3.) Ich habe bei mir systemd-tmpfiles --dry-run --purge tetestet und es hätte mir im /home .config, .cache und .local entfernt. Zudem alle Flatpak-Runtimes uns vieles andere mehr. Teilweise Configs, die ich seit 20 Jahren nutze. Auf stateless systems ergibt das Sinn, die sind bis auf /usr und evtl. /etc oder /var eh temporär. Bei mir hat das eigentlich nichts zu suchen. Und die Daten, die es entfernen wollte, sind auch zu 95% nicht von systemd-tmpfiles erstellt worden. Ich versteh es nicht, vielleicht erleuchtet mich ja noch jemand.

      16

      1. Ja Ferdinand ich verstehe es auch nicht aber so ist es eben wenn man eine krake baut, die an sich das Linux-prinzip aushebelt.

        Leider haben sich viele Distributionen dem Druck der Firmen gebeugt und es wird immer schlimmer.
        Es wird nicht das Letzte sein, wo es so offensichtlich zu Tage tritt.
        Es ist einfach nur schade das man so etwas zu gelassen hat,
        waere vor 20 Jahren nicht moeglich gewesen, da haetten die Firmen Druck machen koennen wie sie wollen.

        7

        1. Nicht hilfreich. Eine spezifische Unschlüssigkeit auf “es ist so, was soll man schon von XYZ anderes erwarten” trägt nicht grade dazu bei, ggf. prozessuale Probleme bei XYZ zu finden, die man dann entweder beheben oder gegen sie nutzen kann.

          P.S.: Ich nutze systemd. Weil viele Distris, die ich aus anderen Gründen bevorzuge, kein alternatives Konstrukt aus Init und weiteren Tools zum Ersatz von systemd anbieten. One task, one tool ist schon lange her.

          3

          1. Genau das habe ich gesagt. Die “Neuen” dran haben eben nicht mehr diese tiefe Verteidigungsbereitschaft. Wenn die Firmen mit Geld winken dann machen sie das eben. … Genau das war frueher anders.

            Es kann daran liegen, das es ja nicht “Ihr Baby” ist.
            Warum auch immer ich verstehe es absolut nicht.

            Natuerlich gibt es immer Ausnahmen etc. und ich will da auch Keinem zu nahe treten aber ansonsten haette sich systemd nicht so verbreiten koennen.
            Es war naemlich keine Notwendigkeit.

            Und der Grundsaty “One task, one tool” zaehlt schon bei vielen noch , vorallem bei GNU Linux Distributionen. (guix, crux etc.)

            1

              1. Schauen was Promox alles an Programmen nutzt und es dann mit devuan nutzen. Man kann in Linux alles machen, auch promox verwendet fertige Einzelprogramme die frei im netzt verfuegbar sind. Ist allerdings etwas arbeit. Man kann auch in einschlaegigen no systemd Foren suchen und fragen.

                0

Kommentar hinterlassen