Fehler in Ubuntu: Wenn kill eine ganze Prozessgruppe beendet

Ein Befehl soll einen Prozess beenden und trifft stattdessen eine ganze Prozessgruppe. Genau dieser Fehler gehört zu einer Reihe von Problemen, die Alan Grow in „A Decade of Kill Bugs“ dokumentiert. Betroffen waren laut Grow mehrere Ubuntu-LTS-Versionen. Für Administratoren und Entwickler liegt die praktische Lehre bei der Eingabeprüfung: Auch ein vertrautes Systemwerkzeug kann aus einem ungültigen Wert eine folgenreiche Aktion machen.

Grows Untersuchung begann nach einem unerwarteten Ausfall, der sich auf einen Fehler in kill(1) zurückführen ließ. Daraus wurde die Analyse einer Fehlerkette über mehr als ein Jahrzehnt. Das macht den Fall für den Betrieb von Linux-Systemen wichtig. Ein kleiner Aufruf kann weit mehr treffen als den vorgesehenen Prozess.

Wie eine ungültige Eingabe zur Prozess-ID 0 wird

Eine der beschriebenen Ursachen betrifft atoi(3), eine Funktion zur Umwandlung von Zeichenketten in Zahlen. Bei der fehlerhaften Verarbeitung nichtnumerischer Eingaben entstand der Wert 0. Für den betroffenen kill-Aufruf blieb dieser Wert nicht folgenlos: Statt einen einzelnen vorgesehenen Prozess zu beenden, wurden alle Prozesse der Prozessgruppe beendet.

Der entscheidende Fehler liegt damit an einer unscheinbaren Grenze. Eine Eingabe ist keine gültige Prozess-ID, wird aber als verwertbare Zahl weitergereicht. Die anschließende Aktion hat eine größere Reichweite, als der Aufrufer beabsichtigt. Aus einem Eingabefehler wird ein Betriebsproblem.

Wer solche Aufrufe in eigenen Skripten oder Verwaltungsprogrammen verwendet, sollte deshalb die Prüfung vor der Aktion untersuchen. Wird eine ungültige Eingabe tatsächlich abgewiesen? Oder gelangt nach einer Umwandlung ein Zahlenwert zum Befehl, der dort eine andere Bedeutung bekommt? Das sind sinnvolle Prüffragen, keine Aussage darüber, dass jedes Skript mit kill betroffen wäre.

Mehrere LTS-Versionen, keine einzelne Panne

Grow dokumentiert Fehler, die nach seiner Darstellung in Ubuntu 14.04, 16.04, 18.04, 22.04 und 24.04 LTS ausgeliefert wurden. Zur untersuchten Reihe gehören außerdem Probleme beim Beenden von Prozessen mittels negativer Prozess-IDs, deren Ursprung Grow bis 2013 zurückverfolgt. Es geht also um mehrere Fehler innerhalb desselben grundlegenden Werkzeugs.

Die Versionsliste ist dabei kein Beleg dafür, dass jede Installation dieser Ubuntu-Ausgaben heute denselben Fehler aufweist. Sie beschreibt, in welchen LTS-Versionen die untersuchten Probleme ausgeliefert wurden. Daraus lässt sich weder ein einheitlicher aktueller Patchstand noch ein identisches Verhalten aller genannten Systeme ableiten.

Für den Betrieb zählt deshalb die konkrete Installation. Eine pauschale Aussage wie „Ubuntu LTS ist betroffen“ hilft bei der Entscheidung über Maßnahmen wenig. Zu prüfen sind der eingesetzte Softwarestand und die Frage, ob die eigenen Abläufe die beschriebenen fehlerhaften Aufrufe überhaupt erreichen können.

Automatisierte Aufrufe verdienen besondere Aufmerksamkeit

Der naheliegende Prüfpunkt sind Abläufe, die Prozess-IDs übernehmen, umwandeln und anschließend an kill weitergeben. Dort sollte eine ungültige Eingabe zum Abbruch führen, bevor eine Aktion ausgelöst wird. Ein Fehler muss als Fehler erhalten bleiben. Er darf nicht unbemerkt zu einem gültig aussehenden Zahlenwert werden.

Tests sollten daher auch nichtnumerische Eingaben und die in der Untersuchung behandelten Sonderfälle berücksichtigen. Solche Prüfungen gehören in eine isolierte Testumgebung. Einen beschriebenen Fehler auf einem produktiven System nachzustellen, wäre angesichts der möglichen Folgen für eine ganze Prozessgruppe die falsche Abkürzung.

Auch bei Updates ist Genauigkeit nötig. Ein geprüftes Update oder ein passender Patch kann eine Maßnahme sein. Ohne Abgleich mit dem konkreten Fehler und dem installierten Stand ist „einfach aktualisieren“ aber noch keine belastbare Lösung.

Vertrautheit ersetzt keine Fehlerprüfung

Grows Analyse widerspricht der bequemen Annahme, ein lange etabliertes Werkzeug brauche kaum noch Aufmerksamkeit. Die beschriebenen Ausfälle entstanden in einem grundlegenden Befehl. Gerade dort kann eine kleine Fehlinterpretation große Folgen haben, weil nachfolgende Aktionen auf dem falsch verarbeiteten Wert aufbauen.

Für Entwickler und Administratoren folgt daraus eine überschaubare Aufgabe: die betroffenen Aufrufe prüfen, ungültige Eingaben konsequent abweisen und den Softwarestand gezielt abgleichen. Das ist weniger aufwendig als eine pauschale Überprüfung sämtlicher alter Systemwerkzeuge. Und es setzt genau an der Stelle an, an der dieser Fall gefährlich wurde: zwischen einer fehlerhaften Eingabe und ihrer Ausführung.

Ähnliche Beiträge