Frage Wie weit werden Sie mit einem 'rm -rf /' Befehl kommen?


Ich habe mich oft gefragt, wie weit das System tatsächlich kommen wird, wenn man rennt rm -rf /. Ich bezweifle, dass das Betriebssystem in der Lage wäre, sich selbst zu löschen (?)

Bonus-Frage: Nachdem der Befehl ausgeführt wurde, wird rm haben sich entfernt?

Aktualisieren: Ich habe dies in einigen der Haupt-Unix-Distributionen mit VirtualBox getestet und die Antworten beschreiben genau, was passiert. Wenn die richtigen Parameter angegeben werden, entfernt rm jedes physikalische Datenbit auf der Disc. Allerdings stieß ich auf einige Probleme, wenn ich eine andere Version von rm als die von GNU verwendete. Zum Beispiel glaube ich, dass BusyBox ihre eigene Version hat und Sie nicht so viel wie möglich entfernen können.

Diese Frage war a Super User Frage der Woche.
  Lesen Sie den 7. Juli 2011 Blog-Eintrag für mehr Details oder reichen Sie Ihre eigenen ein Frage der Woche.


200
2017-07-20 13:48


Ursprung


Es ist lustig, dass du diese Frage gestellt hast. Ich beantwortete gerade eine andere Frage in einem anderen Forum und erinnerte mich an einen Artikel, den ich vor einiger Zeit gelesen hatte. Zum Glück habe ich es für Zeiten wie diese gerettet: DAS klassische Unix-Horrorgeschichte Abgesehen davon, dass es interessant ist, zu sehen, wie weit es gehen wird ... Ich denke, es ist ein sehr gut geschriebener Artikel und ist im Allgemeinen eine gute Lektüre! - akseli
Ich habe es gerade versucht sudo rm -rf / auf tinycore / microcore linux und es scheint, dass das OS schützt mehrere Verzeichnisse (/ sys und andere) vor dem Löschen. - n0pe
Ich habe es versucht rm -f /bin/rm Einmal. Leider funktionierte es und ich verbrachte die nächste Stunde damit, die richtige Version von rm zurück von GNU Coreutils. - squircle
Warte eine Sekunde, ich werde es versuchen ... - Martijn Courteaux
Ich mache das ständig im Apple Store - eggie5


Antworten:


Wenn Sie haben rm von GNU Coreutils (am wahrscheinlichsten, wenn es eine normale Linux-Distribution ist), rm -rf / wird durch den eingebauten Schutz (laut manpage und Wikipedia, habe das nicht ausprobiert) abgelehnt.

Sie können diesen Schutz mit überschreiben --no-preserve-root. rm wird dann alles entfernen, was möglich ist, ohne anzuhalten, nachdem versucht wurde, jede einzelne Datei zu entfernen. Natürlich werden virtuelle Dateisysteme wie /proc und /sys, aber das ist irrelevant - es wird alles auf Ihrer Festplatte entfernen.

Nach dem Beenden des Befehls wird die Festplatte einschließlich des Betriebssystems gelöscht. Der Kernel und die aktuellen Prozesse werden weiterhin aus dem Speicher ausgeführt, aber viele Prozesse werden abstürzen, weil sie nicht auf eine Datei zugreifen können. Das Betriebssystem wird beim nächsten Mal nicht gestartet.


188
2017-07-20 14:36



Genau das, was ich gesucht habe. Jetzt diese Macht nutzen, um die Welt zu erobern. - n0pe
+1 besonders für --no-preserve-root weil das normalerweise nicht erwähnt wird. - Matěj G.
@MaxMackie, es ist erwähnenswert, dass Hacker sehr schnell fanden, dass dies das ist am wenigsten nützliche Dinge, die sie einem Benutzer antun könnten. Es zerstört alle Daten, die für Geldgewinne verwendet werden könnten, und verhindert, dass der Hacker die Maschine weiter ausnutzt. Wie eine Katze mit einem Insekt willst du es nicht töten, du willst nur eine Weile damit spielen, weil es Spaß macht. - zzzzBov
Um die andere Frage des OP zu beantworten, wird yes rm sich selbst entfernen. Es ist durchaus möglich, eine ausführbare Datei zu ändern oder zu löschen, auch wenn gerade eine Instanz läuft. Es läuft auch weiter und wird von der Änderung nicht betroffen sein. - thomasrutter
Ich möchte "/ chmod -R user: user *" an / erwähnen, weil es auch ein rekursiver und kostspieliger Fehler ist. Ich habe es einmal getan und war bis zur Hälfte der Zeit nach Hause gekommen, als ich abbrechen konnte. / bin / boot / etc / dev war im Besitz. Glücklicherweise lief der Server weiter, während ich die nächsten Stunden manuell verbrachte und Besitzer aus einem Referenzsystem zurücksetzte. Jedoch konnte niemand sonst su oder sudo danach verwenden. Schließlich wurde entdeckt, dass / bin / su nicht mehr das Setuid-Bit gesetzt hatte. Beachten Sie für die Zukunft: chowning / bin / su setzt sein setuid Bit zurück! - Andy Lee Robinson


Für diejenigen, die sowas gerne visuell machen, während sie Technomusik hören.

Rmrf unter Linux (Video) ausführen

Bonuspunkte, wenn Sie die Prozesse benennen können, wenn sie zu sterben beginnen.


41
2017-07-20 23:23





Richten Sie eine VM ein und versuchen Sie es zum Spaß?

Es wird ziemlich weit gehen ... wenn du eine Gui verwendest, könntest du Spaß haben, Dinge zu bemerken, die sichtbarer werden. (Symbole in Menüs hören auf zu laden etc.)

Wenn Sie es loslassen, wird das Betriebssystem ziemlich unwiederbringlich sein, obwohl Sie in der Lage sein können, einige Daten leicht zurück zu bekommen.

In jedem Fall werden Sie eine Neuinstallation des Betriebssystems durchführen wollen.


22
2017-07-20 13:52



Ich habe nicht einmal daran gedacht, es in einer VM zu versuchen. Ich werde es jetzt versuchen! ooo das macht Spaß. - n0pe
Versieht den Befehl fälschlicherweise mit dem Terminal des Host-Systems - slhck
Schau dir den Artikel an, den ich gepostet habe. "Die klassische Unix-Horrorgeschichte!" - akseli
Ich bin gerade bei der Arbeit und habe keine Zeit, eine vollständige Installation einer beliebten Distribution (ubuntu / slack / suse / fedora) zu durchlaufen. Wenn jemand anderes eine VM-Disk-Datei klonen und es für uns ausprobieren kann, wäre das großartig. - n0pe
Mit Amazon EC2 sollte es schnell möglich sein, eines ihrer AMIs zu starten, die Linux bereits installiert haben und wegfeuern ... - David d C e Freitas


Nun, versuche es an http://bellard.org/jslinux/ produziert:

rm: kann '/ dev / pts' nicht entfernen: Gerät oder Ressource beschäftigt
  rm: kann '/ dev' nicht entfernen: Verzeichnis ist nicht leer
  rm: '/ proc / swaps' kann nicht entfernt werden: Operation nicht erlaubt
  rm: '/ proc / kallsyms' kann nicht entfernt werden: Operation nicht erlaubt
  rm: kann '/ proc / dma' nicht entfernen: Operation nicht erlaubt

SNIP 881 Einträge

rm: kann '/ proc / 149 / oom_adj' nicht entfernen: Berechtigung verweigert
  rm: kann '/ proc / 149' nicht entfernen: Operation nicht erlaubt
  rm: kann '/ proc' nicht entfernen: Gerät oder Ressource beschäftigt
  rm: kann '/ tmp' nicht entfernen: Gerät oder Ressource beschäftigt
  rm: Kann '/' nicht entfernen: Gerät oder Ressource beschäftigt


11
2017-07-20 14:23



Ja, ich bekomme auch diese Fehler / Warnungen. Ist das dein Standard? - n0pe
/ proc, / sys, manchmal / dev, und alle Mountpoints sind Eigenschaften des Betriebssystems und können nicht gelöscht werden. - pjc50
In Übereinstimmung mit @ pcj50 sind dies keine Dateien auf der Festplatte, daher ist das "Löschen" nicht sinnvoll. - CarlF


Ich erinnere mich daran, dass ich weiterkaute alt.sysadmin.recovery Damals, als es so etwas noch nicht gab /proc, und /dev war nur ein normales Verzeichnis mit Einträgen für ein paar ungewöhnliche Inodes ...

... aber auf einigen Varianten von Unix (meine Erinnerung ist HP-UX, aber das könnte völlig falsch sein), könnten Sie nicht Entfernen Sie den letzten Verzeichniseintrag für ein Programm, das ausgeführt wurde. (Gemeinsame Bibliotheken? Was sind das?)

Auf solchen Systemen, wenn Sie eine im Wartungsmodus gestartet haben (also lief nichts außer Ihrer Shell, nicht einmal init, und keine sekundären Dateisysteme wurden installiert) und tat exec /bin/rm -rf /würden Sie ein komplett leeres Root-Dateisystem erhalten außer Das /bin und /bin/rm würde überleben.

Die Bewohner des unheimlichen Teufelsklosters hielten dies für richtig und angemessen.


7
2017-07-21 00:06





rm -rf / sollte bei neueren Implementierungen nicht erlaubt sein, da es vorgeschlagen wurde, dass es gegen den POSIX-Standard verstößt:

"rm -rf /"Schutz auf Oracle Blog

Wie auch immer, am Ende haben wir die Spezifikation geändert, und Solaris 10 hat (seit Build 36) eine Version von / usr / bin / rm (/ bin ist eine Symlink zu / usr / bin unter Solaris) und / usr / xpg4 / bin / rm, die sich so verhält:

[28] /bin/rm -rf /
rm of / is not allowed
[29] 

4
2017-07-20 15:58



"Wenn man versucht," / "rekursiv zu entfernen, versucht man letztendlich," .. "und". "zu entfernen, und das alles, was wir tun, ist, dass rm das heuristisch vorher bestimmen kann. Erstaunlicherweise haben sie das gekauft ! "- äh, würde das Entfernen nicht verbieten irgendein Verzeichnis? Die tatsächliche Spezifikation lässt nur .. und. in den eigentlichen Befehlszeilenargumenten sagt es nichts darüber aus, was Sie "letztendlich versuchen zu entfernen" - Random832
Warum sollte es nicht möglich sein, ein Verzeichnis zu entfernen? Das Root-Verzeichnis ist das einzige, das hier betroffen ist, und das Entfernen des Verzeichnisses bedeutet offensichtlich das Entfernen von "." und "..", was auch immer das aktuelle Verzeichnis ist. Der gesunde Menschenverstand ist in der Standardinterpretation nicht verboten. - jlliagre
Diese Argumentationslinie ist pures Genie. - Nate C-K
Der Standard gibt an, dass rm nicht fortgesetzt werden darf wenn ein Argument die Zeichenfolge "." oder ".." als Basenname-Komponente. Sie können nicht entfernen /foo/.. auch wenn du nicht da bist /foo. Es tut nicht Geben Sie an, dass das aktuelle Verzeichnis nicht entfernt werden darf (z. rm -r `pwd`) oder das übergeordnete Element des aktuellen Verzeichnisses. - Random832
In der Tat habe ich die Aussage missverstanden und Sie haben Recht. Hoffentlich akzeptierten die Standard-Typen das intelligentere Verhalten als standardkonform. Das Entfernen von großen Teilen, wenn nicht das gesamte Dateisystem, würde das OS schnell sowieso nicht standardkonform machen. - jlliagre


Ein Punkt, den ich von niemand anderem gesehen habe: Dateien, die gerade geöffnet sind (z. B. rm selbst), werden, selbst wenn sie gelöscht werden, nicht wirklich vom Laufwerk verschwinden, bis sie geschlossen sind.


3
2017-07-20 17:12



Das ist richtig, weil sie im Speicher geladen sind, oder? - n0pe
Ich bin nicht sicher, ob das sicher anzunehmen ist; der Kernel könnte sehr gut die entfernte Datei einfach in den Speicher laden und sofort auf der Platte entfernen und diese In-Memory-Kopie behalten, bis die Datei geöffnet ist (z. B. bis rm läuft). - Ambroz Bizjak
Ich spekuliere nicht. Wenn ein Programm läuft, lösche ich es nicht auf meinen Linux-Boxen. (Wohlgemerkt, ich habe das in, oh, ein paar Jahren nicht getestet.) - CarlF
rm  werden entfernen sich von den fs - die Programm ist vollständig im Speicher geladen, nicht die Datei - warren
@ MaxMackie: Nicht, weil sie in Arbeitsspeicher geladen sind, sondern weil eine geöffnete Dateiverweis die gleiche Stärke wie eine feste Verbindung (d. H. Wenn eine Datei mindestens eine feste Verknüpfung hat, wird es nicht von der Festplatte gelöscht). - Lie Ryan


Weil ich es einmal probiert habe (auf einem Server, der mich nervt), als Root angemeldet, im Terminal, wirst du fast alles verlieren. Das einzige, was nicht gelöscht wird, ist nur der Prozess, der für das Betriebssystem notwendig war.


1
2017-07-20 13:55



"[nicht gelöscht] nur der Prozess, der für das OS notwendig war" - oh, mach dir keine Sorgen. Im Gegensatz zu Windows wird Linux gerne alles löschen, selbst wenn die Datei betriebssystemkritisch ist und in Benutzung. /boot, /sbin, /etc, /bin, /vmlinuz? Bam, weg. Viel Glück ohne diese zu booten - in der Tat viel Glück dabei etwas nachdem das Löschen beendet ist. - Piskvor
Wenn ich mich erinnere, gab es eine Datei, die nicht gelöscht wurde, und ich ließ mein Linux für mehr als 4 Stunden laufen. Aber immer noch, es ist gut zu wissen, was passiert, wie ein chmod 777 / * -fR;) - Anarko_Bizounours
"chmod 777 / * -fR" - Das sollte das System sehr unsicher machen, obwohl es sehr benutzerfreundlich ist. - Bart van Heukelom
Hab es gemacht, es ist sehr unsicher. Sie können nichts tun, ein Prozess muss ein spezifisches Recht haben, und das chmod 777 wird jedes Recht ändern, Sie werden nie in der Lage sein, eine Sitzung zu laden, und einige Prozesse dazu. - Anarko_Bizounours
@BartvanHeukelom, einige Tools führen einen schnellen Selbsttest durch oder werden vom System auf ordnungsgemäße Eigentümer und Berechtigungen geprüft und weigern sich zu handeln, wenn sie falsch konfiguriert sind. - killermist


Wie weit Sie kommen können, hängt im Wesentlichen von den spezifischen Unix / Linux-Distributionen ab.

Aber um deine Grundfrage zu beantworten, ja - rm Der Befehl würde damit ebenso wie jeder andere Standardbefehl in entfernt werden /bin und andere Ordner.

Hier ist der einfache Test, den ich in Linux Ubuntu 15.04 mit VM durchgeführt habe.

  1. Initialisieren Sie die virtuelle Maschine über vagrant:

    vagrant init ubuntu/vivid64 && vagrant up --provider virtualbox && vagrant ssh
    
  2. Wenn Sie dann versuchen, alle Dateien auf die übliche Weise zu entfernen, lässt es Sie nicht:

    vagrant@vagrant-ubuntu-vivid-64:~$ sudo rm -fr /
    rm: it is dangerous to operate recursively on '/'
    rm: use --no-preserve-root to override this failsafe
    
  3. Lass es uns versuchen --no-preserve-root. Überprüfe immer, ob du in der virtuellen Maschine angemeldet bist (also hast du) vagrant@vagrant-ubuntu-vivid-64:~$), dann lauf (versuche das nicht zu Hause):

    vagrant@vagrant-ubuntu-vivid-64:~$ sudo rm -vfr --no-preserve-root /
    removed directory: '/lost+found'
    removed directory: '/opt'
    removed '/bin/nc'
    removed '/bin/less'
    removed '/bin/wdctl'
    removed '/bin/nano'
    ...
    removed '/bin/rmdir'
    removed '/bin/sh'
    removed '/bin/rm'
    ...
    removed directory: '/bin'
    removed directory: '/usr/games'
    removed '/usr/bin/byobu-launcher-install'
    removed '/usr/bin/ipcmk'
    removed '/usr/bin/sum'
    removed directory: '/usr/bin'
    removed '/usr/lib/gcc/x86_64-linux-gnu/4.9.2'
    removed '/usr/lib/gcc/x86_64-linux-gnu/5.0.1'
    removed directory: '/usr/lib/gcc/x86_64-linux-gnu/5'
    removed '/usr/lib/gcc/x86_64-linux-gnu/4.9/libquadmath.so'
    removed '/usr/lib/gcc/x86_64-linux-gnu/4.9/libgomp.so'
    ...
    removed directory: '/run/initramfs'
    removed directory: '/media'
    rm: cannot remove '/proc/fb': Operation not permitted
    rm: cannot remove '/proc/fs/ext4/sda1/options': Operation not permitted
    ...
    removed '/vmlinuz'
    removed '/boot/config-3.19.0-23-generic'
    removed '/boot/grub/grubenv'
    ...
    removed directory: '/boot'
    removed '/lib64/ld-linux-x86-64.so.2'
    rm: cannot remove '/dev/hugepages': Device or resource busy
    rm: cannot remove '/dev/mqueue': Device or resource busy
    rm: cannot remove '/dev/shm': Device or resource busy
    removed '/dev/vcsa7'
    ...
    removed '/dev/mem'
    removed '/dev/rfkill'
    removed '/dev/vga_arbiter'
    ...
    rm: cannot remove '/sys/fs/ecryptfs/version': Operation not permitted
    removed directory: '/etc'
    removed directory: '/mnt'
    removed '/vagrant/.vagrant/machines/default/virtualbox/action_provision'
    removed '/vagrant/.vagrant/machines/default/virtualbox/action_set_name'
    removed '/vagrant/.vagrant/machines/default/virtualbox/creator_uid'
    removed '/vagrant/.vagrant/machines/default/virtualbox/id'
    removed '/vagrant/.vagrant/machines/default/virtualbox/index_uuid'
    removed '/vagrant/.vagrant/machines/default/virtualbox/private_key'
    removed '/vagrant/.vagrant/machines/default/virtualbox/synced_folders'
    removed directory: '/vagrant/.vagrant/machines/default/virtualbox'
    removed directory: '/vagrant/.vagrant/machines/default'
    removed directory: '/vagrant/.vagrant/machines'
    removed directory: '/vagrant/.vagrant'
    removed '/vagrant/Vagrantfile'
    rm: cannot remove '/vagrant': Device or resource busy
    

    Danach kommt es zurück zur Shell-Eingabeaufforderung, als wäre nichts passiert, aber Sie können keine Befehle mehr ausführen, abgesehen von einigen eingebauten und kill, damit du deinen Job beenden und deine Session beenden kannst :)

    Beispielsweise:

    $ rm
    rm: command not found
    $ kill
    kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
    $ which kill
    -bash: /usr/bin/which: No such file or directory
    $ kill -9 $$
    Connection to 127.0.0.1 closed.
    

So hat es ziemlich alles einschließlich entfernt rm, ls und alle anderen Befehle, aber trotzdem sind Sie eingeloggt. Es gibt einige spezielle Ordner, die nicht entfernt wurden, wie manche Geräte von /dev, /proc oder /sys Das sind keine regulären Verzeichnisse / Dateien, aber es ist ein Pseudo-Dateisystem, das Schnittstellen zu Prozess- und Kerneldaten bereitstellt.

Wenn Sie Vagrant oder Linux nicht haben, können Sie mit einigen spielen JavaScript Linux x86-Emulatoren.

Wenn Sie an Möglichkeiten interessiert sind, sich von einer solchen Katastrophe zu erholen, überprüfen Sie:


1
2017-09-27 15:17