Warum ist das schreckliche 'rm -rf /' überhaupt erlaubt? [geschlossen]

Wir alle kennen die zerstörerische Kraft des folgenden Befehls, der als root ausgeführt wird:

rm -rf /

Verwandte Fragen:

Ich sehe nicht ein, wann diese spezielle Kombination von Parametern nützlich wäre, da sie das gesamte System zerstört und es effizientere Möglichkeiten gibt, dies zu tun. Der rmBefehl könnte nach diesen spezifischen Parametern suchen und eine Art Schutz implementieren - trotz des -fParameters zumindest um Bestätigung bitten .

Warum gibt es keinen solchen Schutz im rmBefehl?

Mir ist klar, dass Sie besonders vorsichtig sein müssen, wenn Sie Befehle als root ausführen. Mit großer Kraft (...) . Sollte dieser spezielle Fall jedoch keine Ausnahme von dieser Regel sein?

— Laurent Pireyn
quelle

Ich stelle mir vor, dass es eine philosophische Tendenz dagegen gibt. Wo sollten Sie aufhören, wenn Sie erst einmal damit begonnen haben, Benutzer vor sich selbst zu schützen?

— dmckee --- Ex-Moderator Kätzchen

Wie viele habe ich diesen Fehler schon einmal gemacht (eigentlich rm -r $ variable / als sich herausstellte, dass $ variable leer ist). Ich beschuldige mich selbst, dumm zu sein, nicht die O / S, meine Hand nicht zu halten, und ich würde es nicht anders wollen.

— Sirex

Was ist, wenn danach rm -rf /durchgeführt wird chroot?

— Mouviciel

@ Sirex Ich kenne diese Situation ziemlich gut. set -uist dein Freund. Wenn Sie jedoch einstellen variable=, kann Sie nichts außer defensiver Programmierung retten.

— Daniel Beck

Der Befehl kann UEFI-Geräte

— blockieren

Antworten:

Das hängt von der Verteilung ab. Das ältere Linux, auf dem ich gerade bin, erlaubt es (ich denke, habe es aber nicht getestet :-)) und sagt in man rm:

   --no-preserve-root do not treat '/' specially (the default)

   --preserve-root
          fail to operate recursively on '/'

Bei vielen neueren Distributionen müssen Sie explizit hinzufügen --no-preserve-root, um den Schutz zu deaktivieren. Andernfalls kann es nicht ausgeführt werden.

Informationen zu Ubuntu finden Sie in diesem Problem, in dem dieses Verhalten erläutert wird.

Die Geschichte dieses Schutzes laut Wikipedia :

Sun Microsystems hat rm -rf /in Solaris 10 den Schutz eingeführt , der erstmals 2005 veröffentlicht wurde. Nach Ausführung des Befehls meldet das System nun, dass das Entfernen von /nicht zulässig ist. Kurz darauf wurde dieselbe Funktionalität in die FreeBSD-Version des rmDienstprogramms eingeführt. GNU rmlehnt die Ausführung ab, rm -rf /wenn die --preserve-rootOption angegeben wird. Dies ist die Standardeinstellung seit der Veröffentlichung von Version 6.4 von GNU Core Utilities im Jahr 2006.

— Daniel Beck
quelle

+1: Das wusste ich nicht (und habe es nicht in einer VM versucht). Also ich denke meine Frage ist etwas spät ...

— Laurent Pireyn

Können Sie die von Ihnen verwendete Linux-Distribution und -Version angeben?

— Laurent Pireyn

@Laurent Ich habe meine Antwort in der Zwischenzeit bearbeitet. Ich bin gerade auf RHEL5.6 und es erlaubt den Befehl standardmäßig .

— Daniel Beck

Und dank @slhck wissen wir jetzt, warum mein RHEL es nicht mag, es ist Software von Anfang 2006 AFAICT.

— Daniel Beck

@slhck Das glaube ich nicht.

— Daniel Beck

Warum gibt es im Befehl rm keinen solchen Schutz?

Es gibt bereits drei Sicherheitsvorkehrungen:

Der -rSchalter, ohne den ein Verzeichnis nicht entfernt werden kann.
Der -iSchalter, der überprüft, ob Sie tatsächlich löschen möchten, was Sie zum Löschen aufgefordert haben. Aliasing rm, rm -ium diesen Schutz einzuschalten , es sei denn, Sie fügen den -fSchalter hinzu, um ihn auszuschalten.
Dateibesitz, der verhindert, dass alle Benutzer rootdas Stammverzeichnis löschen.

Das Unix-Toolset ist wie eine Kettensäge: Es wurde entwickelt, um sehr mächtige Dinge zu tun und von Leuten benutzt zu werden, die verstehen, was sie tun. Diejenigen, die nachlässig treten, werden sich wahrscheinlich selbst verletzen. Dies bedeutet nicht, dass die Erfahrenen keine Fehler machen, und offensichtlich haben Sun und andere das Gefühl, dass Benutzer mit rootSchutz vor sich selbst geschützt werden müssen.

Sollte dieser spezielle Fall jedoch keine Ausnahme von dieser Regel sein?

Die Leute haben gefragt, warum wir rmseit mindestens den 1980er Jahren keinen Klingenschutz mehr über die Kettensäge legen können . (Wahrscheinlich länger, aber meine Geschichte mit Unix geht nicht weiter zurück.) Sie müssen sich weitere Fragen stellen:

Was sollte noch als heilig angesehen werden, da wir Ausnahmen hinzufügen? Sollten wir das rekursive Löschen von Elementen im Stammverzeichnis verhindern, um ebenso verheerende Fehler wie zu vermeiden rm -rf /*? Was ist mit dem Home-Verzeichnis des Benutzers? Was ist mit /liboder /bin? Müssten wir eine spezielle Version von haben rm, um diese Fehler auf Systemen mit einem nicht traditionellen Dateisystemlayout zu vermeiden?
Wo setzen wir die Durchsetzung dieser Verbote ein? Nur in rmoder geben wir dem Kernel diesen Job? Da rmnichts gelöscht wird (es werden viele Aufrufe an unlink(2)und rmdir(2)basierend auf den Argumenten rmgetätigt ), würde der Kernel keine Möglichkeit erkennen, zu erkennen, worauf es wirklich ankommt, /bis der Moment gekommen ist, es tatsächlich zu löschen. Da der einzige Aufruf rmdir(2)dazu jemals erfolgreich sein würde, wenn das Zielverzeichnis leer ist, würde das Erreichen dieses Punktes mit /bedeuten, dass das System bereits erledigt ist.

— Blrfl
quelle