Einen eindrucksvollen Beleg für die mögliche Schädlichkeit von Shell-Skripten lieferte das amerikanische Softwareunternehmen Valve. Die Linux-basierte Version des Spielediensts Steam brachte ein Skript mit, das normalerweise nur für kleinere Einrichtungsaufgaben zuständig war. Verhängnisvollerweise [1] fand sich dort folgende Passage:
rm -rf "$STEAMROOT/"*
Dieses für das Löschen des Verzeichnisses "$STEAMROOT" verantwortliche Kommando bekommt Probleme, wenn die Umgebungsvariable nicht gesetzt ist. Die Bash-Shell löst dann keinen Fehler aus, sondern "zerlegt" die Umgebungsvariable einfach zu einem leeren String. Lohn der Mühen ist folgendes Kommando, das sich rekursiv durch das gesamte Dateisystem arbeitet und alle Informationen zerstört:
rm -rf "/"*.
Einige Benutzer entgingen einem Totalverlust dadurch, dass ihre Steam-Ausführungsumgebung unter SELinux-Jail lief. Andere waren nicht so glücklich, weshalb es an der Zeit ist, sich Maßnahmen zur defensiven Programmierung von Shell-Skripten näher anzusehen.
Unter unixoiden Betriebssystemen stehen Dutzende von Shells zur Verfügung, die sich nur durch die Unterstützung des POSIX-Standards ähneln und diverse proprietäre Funktionen mitbringen. Bei der Nutzung von Shell-spezifischem Code in anderen Shells tritt oft ein undefiniertes Verhalten auf. Dies mag in einer kontrollierten VM-Umgebung kein Problem sein, doch das Deployment in einem Docker- oder sonstigem Cluster ändert die Lage.
Das häufigste Problem ist die Verwendung der als Shebang bezeichneten Sequenz "#!/bin/sh", die gemäß POSIX-Standard die vom System vorausgewählte Shell betrifft. Ein Shebang ist unter Unix eine mit "#!" beginnende erste Zeile eines Skripts. Sie legt fest, welcher Interpreter für die Abarbeitung des
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.