Warum gibt es keinen solchen Schutz im rm-Befehl?
Es gibt bereits drei Schutzmaßnahmen:
- Der
-rSchalter, ohne den ein Verzeichnis nicht entfernt werden kann. - Die
-iSchalter, der überprüft, ob Sie tatsächlich löschen möchten, was Sie löschen möchten. Aliasingrmbisrm -ischaltet diesen Schutz ein, es sei denn, Sie fügen den-fhinzu schalten, um es auszuschalten. - Dateibesitz, der alle Benutzer außer
rootverhindert vom Löschen des Root-Verzeichnisses.
Das Unix-Toolset ist wie eine Kettensäge:Es wurde entwickelt, um sehr mächtige Dinge zu tun und von Leuten geführt zu werden, die verstehen, was sie tun. Wer unachtsam vorgeht, riskiert, sich selbst zu verletzen. Das soll nicht heißen, dass Erfahrene keine Fehler machen, und offensichtlich glauben Sun und andere, dass Benutzer mit root müssen vor sich selbst geschützt werden.
Sollte dieser spezielle Fall jedoch nicht eine Ausnahme von dieser Regel sein?
Die Leute haben gefragt, warum wir den rm nicht mit einem Klingenschutz versehen können Kettensäge seit mindestens den 1980er Jahren. (Wahrscheinlich länger, aber meine Geschichte mit Unix reicht nicht weiter zurück.) Sie müssen sich weitere Fragen stellen:
-
Da wir Ausnahmen hinzufügen, was sollte sonst noch als heilig betrachtet werden? Sollten wir das rekursive Löschen von irgendetwas im Stammverzeichnis verhindern, um ebenso verheerende Fehler wie
rm -rf /*zu vermeiden ? Was ist mit dem Home-Verzeichnis des Benutzers? Was ist mit/liboder/bin? Müssten wir eine spezielle Version vonrmhaben um diese Fehler auf Systemen mit einem nicht-traditionellen Dateisystem-Layout zu verhindern? -
Wohin stellen wir die Durchsetzung dieser Verbote? Gerade in
rmoder geben wir dem Kernel diese Aufgabe? Seitrmlöscht eigentlich nichts (es macht viele Aufrufe anunlink(2)undrmdir(2)basierend auf den Argumenten), gäbe es für den Kernel keine Möglichkeit, diesenrmzu erkennen war wirklich scharf auf/bis der Moment kam, es tatsächlich zu löschen. Da wird nurrmdir(2)aufgerufen Das würde immer gelingen, wenn das Zielverzeichnis leer ist und dieser Punkt mit/erreicht wird würde bedeuten, dass das System bereits erledigt ist.
Es kommt auf die Verteilung an. Das ältere Linux, auf dem ich mich gerade befinde, erlaubt es (glaube ich, habe es aber nicht getestet :-) ) und gibt in man rm an :
--no-preserve-root do not treat '/' specially (the default)
--preserve-root
fail to operate recursively on '/'
Bei vielen neueren Distributionen müssen Sie explizit --no-preserve-root hinzufügen um die Sicherung zu deaktivieren. Andernfalls kann es nicht ausgeführt werden.
In Bezug auf Ubuntu siehe diese Ausgabe, in der dieses Verhalten diskutiert wird.
Die Geschichte dieses Schutzes laut Wikipedia:
Sun Microsystems führte rm -rf / ein Schutz in Solaris 10, das erstmals 2005 veröffentlicht wurde. Beim Ausführen des Befehls meldet das System nun, dass das Entfernen von / ist nicht erlaubt. Kurz darauf wurde die gleiche Funktionalität in die FreeBSD-Version von rm eingeführt Dienstprogramm. GNU rm weigert sich, rm -rf / auszuführen wenn der --preserve-root Option angegeben, die seit der Veröffentlichung von Version 6.4 von GNU Core Utilities im Jahr 2006 die Standardeinstellung ist.