Vraag Hoe kan 'rm -rf /' alle bestanden in het systeem verwijderen?


Ik heb dit bevel niet op Ubuntu geprobeerd (om voor de hand liggende redenen), dus ik weet niet zeker of Ubuntu de uitvoering ervan toestaat. Maar het staat erom bekend alles te verwijderen. Gewoon uit nieuwsgierigheid, wat gebeurt er als de kernel en /bin zijn verwijderd? Hoe werkt het rm een looptijd bijhouden? Hoe werkt het rm lukt het om te communiceren met het bestandssysteem en het verwijderen te voltooien? Hoe communiceert het met hardware?


80
2018-04-02 08:13


oorsprong


rm -rf / verwijdert niets zonder --no-preserve-root. - muru
Mijn allereerste ervaring met Linux was het maken van een Ubuntu vm zodat ik het kon "rm -rf /". Ik raad aan dat je dit probeert. Het is vrij snel in te stellen, het houdt je host veilig en is erg vermakelijk om te zien hoe de verschillende delen van het OS voor je ogen instorten. Zeer bevredigend. - DJMcMayhem
Doet me denken aan mijn favoriete ingetogen bugrapport: bugzilla.redhat.com/show_bug.cgi?id=1202858   "Verwachte resultaten: Squid wordt opnieuw gestart. Werkelijke resultaten: alle bestanden worden op de machine verwijderd."
Je zou moeten lezen Unix Recovery Legend. Zolang je nog ingelogd bent in een shell, is het systeem niet helemaal dood! - 200_success
@gerrit ik deed. :) - muru


antwoorden:


Dat doet er niet toe /bin/rm is verwijderd. Het wordt maar één keer uitgevoerd en op dat moment is het allemaal in het geheugen geladen, net als al het andere dat nodig is om deletes naar het bestandssysteem en de schijf te blijven sturen.


Sidebar / Update: Per David Hoelzer's antwoord (en vermeld in de opmerkingen), de inode de hardlink /bin/rm gebruikt om naar te wijzen zou tot en met rm klaar (omdat Linux in een open status staat) maar dat feit is niet relevant; de toestand van de schijf doet er helemaal niet toe.

Het binaire bestand wordt in het geheugen geladen voordat het wordt uitgevoerd. Zelfs als je de rm schijfgegevens, het zou niet van invloed zijn of stoppen met het verwijderen van de schijf (ervan uitgaande dat u de schijf anders niet onbeschikbaar zou maken).

Geen idee wat een inode of hardlink is? Dit is het antwoord waar ik het uitwerkte.


Hoe dan ook, dit is ook de reden waarom je het pakket voor de kunt verwijderen actueel kernel zonder dat de computer implodeert. Zolang u een andere versie installeert, kan deze worden opgestart.

Nogmaals, dit werkt omdat rm wordt slechts één keer genoemd. Het volgende zou mislukken na /bin/rm stierf omdat het eenmaal voor elke bestandsnaam wordt genoemd:

find / -exec rm {} \;

Dat gezegd hebbende, find / -exec rm -rf {} + en find / -print0 | xargs -0 rm -rf zou ook beide waarschijnlijk falen omdat ze beiden argumentgrenzen hebben, wat betekent dat ze alleen een aantal bestanden verwijderen voordat ze opnieuw worden gebeld. Op een bepaald moment tijdens de reis, /bin/rm kan vervallen (en worden vrijgegeven) voordat de rest van de bestanden werden verwijderd. Het is echter niet gegarandeerd. Als /bin/ waren de laatste directory ingevoerd, deze methoden kon werk.


76
2018-04-02 08:26



Zoals @DavidHoelzer uitlegt, hoeven niet-gelinkte bestanden niet al in het geheugen te zijn om te blijven werken. De kernel weet dat er een open bestandsingreep is, dus het houdt de bestandsgegevens rond om te voldoen aan alle verzoeken (inclusief pagina-ins) totdat de laatste handle gesloten is. - Andrew Medico
@Desty, nee, dat zou niet lukken, zolang als /bin/rm is niet dichtbij genoeg om het einde te zijn van de allerlaatste batch; -exec ... {} + (de backslash die ontsnapt is overbodig) resulteert nog steeds in meerdere uitvoeringen; niet één per bestand, maar één per batch op basis van het aantal argumenten dat in ARG_MAX past. - Charles Duffy
@ Oli, het gaat niet om paging; referentietellers zijn gekoppeld aan de inode, niet aan het telefoonboekitem en een open bestandhandvat telt als een referentie (hetzelfde als een harde koppeling), waardoor wordt voorkomen dat de inode wordt verwijderd. Bestandsgrootte is helemaal geen factor, en dit gebeurt zelfs als er helemaal geen swapspace (dus geen paging) is. - Charles Duffy
@CharlesDuffy Ongeacht of u over swapspace beschikt of niet, paging wordt gebruikt voor alle geheugen toegewezen bestanden. Dat omvat alle uitvoerbare bestanden en bibliotheken. In feite kan een gebrek aan swapruimte in feite betekenen dat er meer paging plaatsvindt voor geheugen gemapte bestanden. - kasperd
@CharlesDuffy Ja, de grootte is inderdaad niet relevant. Als u een bestand in het geheugen toewijst, wordt de inhoud van het bestand pas geladen nadat u het hebt geopend. En het geheugen dat wordt gebruikt om de gevonden delen van het bestand te laden kan indien nodig opnieuw worden vrijgegeven, waarna het opnieuw uit het bestand wordt geladen als het opnieuw wordt gebruikt. Het bestand moet dus inderdaad in het bestandssysteem blijven zolang het is toegewezen, en dit gedraagt ​​zich op dezelfde manier voor een bestand van één pagina als voor een bestand dat groot genoeg is om de volledige adresruimte te overbruggen. (De details zijn iets gecompliceerder voor copy-on-write-toewijzingen die nodig zijn voor dynamische koppeling.) - kasperd


Ik heb dit bevel niet op Ubuntu geprobeerd (om voor de hand liggende redenen), dus ik weet niet zeker of Ubuntu de uitvoering ervan toestaat.

Ik deed. rm -rf / --no-preserve-root draaide in een root-sessie die direct op de machine werd geopend, terwijl ik ook was verbonden via ssh vanaf een andere machine, ook met behulp van de root-account.

Wat er gebeurt, is dat je begint te krijgen veel van berichten zoals:

rm: kan '/ ...' niet verwijderen: bewerking niet toegestaan

of:

rm: kan '/ ...' niet verwijderen: apparaat of bron bezig

enter image description here

Verrassend genoeg, ssh verbinding bleef geopend tot het einde van de operatie. Het is pas toen ik de verbinding sloot en probeerde opnieuw te openen dat er een fout verscheen:

Lezen van socket mislukt: verbinding gereset door peer

Op de machine blijven vier mappen over:

  • /dev. Hier worden apparaatbestanden opgeslagen.
  • /proc-In-memory bestandssysteem gecreëerd door de kernel.
  • /run, een gestandaardiseerde locatie van het bestandssysteem voor daemons.
  • /sys. Hiermee kunt u informatie over het systeem en zijn componenten verkrijgen.

Dit betekent dat er niet veel meer over is en er niet veel te doen is. Dat kan niet ls (hoewel bij gebruik tab, de namen van mappen en bestanden worden nog steeds weergegeven). Jij kan cd in verschillende mappen, en ook echo dingen, maar commando's zoals cat zijn niet langer beschikbaar.

Er is geen sudo een van beide.

shutdown -h now en reboot is ook verdwenen, dus je enige optie lijkt de machine handmatig neer te zetten. Uitloggen (exit) werkt niet, zelfs als het een mooie "afmeldtekst" laat zien.

Zodra je de machine opnieuw probeert op te starten, krijg je een aardige GRUB-fout 15 te zien, en dan gebeurt er niets, op dat moment begin je te denken dat je rm misschien iets slecht voor je systeem gedaan.

enter image description here

Je kunt het ook doen

Nee, wacht, doe het niet op uw machine!

Wat u in plaats daarvan kunt doen, is om een virtuele machine. VM's hebben het voordeel dat experimenten heel eenvoudig zijn. Omdat u Ubuntu gebruikt, bent u misschien geïnteresseerd in vmbuilder. Dit is een tool waarmee u binnen enkele minuten virtuele machines kunt inzetten (de officiële documentatie beweert dat het "in ongeveer een minuut" kan worden gedaan, maar de werkelijke tijd, zelfs op snelle hardware, is meer ongeveer twee-drie minuten .

Zodra de implementatie is beëindigd, hebt u een omgeving waarin u kunt spelen. Als je het uiteindelijk vernietigt, maakt het niet uit: je implementeert het apparaat opnieuw en twee minuten later kun je doorgaan.

Als u software zoals VMWare gebruikt, bent u mogelijk ook geïnteresseerd in snapshots (merk op dat de gratis VMWare Player deze functie niet heeft, je moet VMware Workstation kopen). Merk op dat Hyper-V gratis is en snapshots ondersteunt (maar je moet Windows draaien).

Het voordeel van snapshots is dat je er een kunt maken in een kwestie van milliseconden. Teruggaan naar een snapshot duurt langer, maar is vaak een kwestie van seconden. Dit maakt het experimenteren nog eenvoudiger en sneller.

Deze experimenten zijn niet beperkt tot het besturingssysteem zelf. Je kunt van alles doen met software. Heb je een verdachte applicatie? Test het in een VM - als het een virus is, zal het geen kwaad. Wilt u een bewerking testen in een database, omdat dit de omgeving kan beïnvloeden? Test het in een VM.

Wat als je dat deed op een echte machine zonder test?

Er gebeuren slechte dingen. Let daar op rm beschermt je tegen jezelf: rm -rf / zal niet werken: je moet gebruiken --no-preserve-root. Maar wat als je per ongeluk alles hebt verwijderd?

rm ontkoppelt alleen bestanden, maar de gegevens staan ​​nog steeds op je harde schijf. Dit maakt het mogelijk om het later te herstellen (daarom zou u uw harde schijven niet met gevoelige gegevens moeten weggooien als ze niet langer werken).

Dit betekent dat u alleen een reserve-pc met een harde-schijfbehuizing hoeft te hebben om deze bijna te herstellen alle de bestanden. Het belangrijkste is om te voorkomen dat er iets op de harde schijf wordt geschreven om te herstellen: de gegevens die u schrijft overschrijven de niet-gekoppelde bestanden.

Zoals opgemerkt in het artikel in de opmerking van 200_success, als u slim handelt, kunt u de machine terug krijgen, zelfs zonder een reserve pc. Als je alleen om gegevens geeft, zou ik niet de moeite nemen - het herstellen met een reserve-pc is veel eenvoudiger.


54
2018-04-02 18:06



VirtualBox ondersteunt disk snapshots. - Nathan Osman
Merk op dat virussen vaak ontworpen zijn om VM's te detecteren, dus ik zou dit virusdetectieproces niet adviseren. Een kleine vraag: die overblijvende vier mappen zijn geen "echte" mappen, toch? Ze zijn niet echt op de harde schijf? Wat blijft er op de harde schijf staan ​​na het uitvoeren van dit commando? - raptortech97
@ raptortech97 rm niet echt dingen van de harde schijf wist, het "ontkoppelt" (disassocieert) de feitelijke gegevens op de schijf uit de bestandssysteemboom en markeert deze gratis (zodat deze mogelijk uiteindelijk wordt overschreven door normaal computergebruik). Dus als je, laten we zeggen, rm -rf ~, niet alles is verloren, zolang je maar snel handelt (bijvoorbeeld met extundelete). Je kunt het beschouwen als een nog onbetrouwbaardere versie van de "verwijderde" map in je mailbox, je kunt dingen terugkrijgen als je niet te lang wacht, maar uiteindelijk wordt het gewist. - Thomas
@ raptortech97 Aan de andere kant, als je om wat voor reden dan ook niet hebt gebruikt rm maar shred, het is zo ongeveer game-over, hoewel je waarschijnlijk tijd hebt om je fout te realiseren en af ​​te breken omdat shredden langer duurt. - Thomas
De mappen die worden bijgehouden zijn hoogstwaarschijnlijk mount-punten van een of andere vorm. En de opdrachten die blijven werken zijn bash ingebouwde opdrachten, geen afzonderlijke binaries. Dus terwijl lsis weg, for i in /*; do echo $i; done zou moeten werken. En om te vervangen cat je zou een commando zoals kunnen gebruiken while read i; do echo $i; done < /proc/self/maps. - MvG


De reden is dat de bestandsnaamgevingslaag (wat je ziet met ls) is echt alleen voor uw gemak. Het bestandssysteemstuurprogramma en de kernel zorgen alleen voor wat de inode is. Wanneer naar een bestand wordt verwezen met een naam, wordt dit onmiddellijk vertaald in de inode die alle metadata bevat, inclusief de machtigingen, de datablokken op de schijf, de eigenaar-ID, de groeps-ID en het aantal verbindingen.

De koppeling telt is wat er echt toe doet. Wanneer u een bestand op een UNIX-systeem verwijdert, is de werkelijke systeemaanroep een unlink. Wat er gebeurt onder de motorkap is dat het aantal verbindingen (het aantal bestandsnamen in de bestandsnaamgevingslaag) dat naar die inode wijst, wordt verlaagd. Het bestandssysteem weet dat een bestand wordt verwijderd wanneer het aantal verbindingen nul is.

Wanneer een bestand wordt verwijderd door rm het zal ook het mapbestand bewerken (ja, het is slechts een bestand dat de bestandsnaam en de inode bevat, naast een paar andere bits die niet belangrijk zijn voor dit antwoord). Het is echter de ontkoppeling die daadwerkelijk de schijfbronnen bevrijdt.

Dit leidt tot een aantal andere interessante effecten. Ten eerste is het mogelijk om een ​​bestand te openen waarvan het aantal verbindingen nul is. Dit gebeurt wanneer rm -rf / verwijdert de invoer voor /bin/rm. Het bestand is open (er is een bestandsingreep), maar de inode is gemarkeerd als verwijderd (aantal koppelingen = 0). De schijfbronnen worden niet vrijgegeven en opnieuw gebruikt totdat de bestandsingang wordt gesloten.

Een ander interessant effect is wat er gebeurt als u een inode hebt met een aantal koppelingen dat groter is dan nul maar niets in de bestandsnaamgevingslaag die ernaar verwijst. Dit is in zekere zin een zeer goed verborgen bestand :). Om toegang te krijgen, zou je iets laags moeten gebruiken om te verwijzen naar inodenummer in plaats van naar naam (omdat er geen is) of een directoryitem bewerken om naar de inode te wijzen met behulp van een hex-editor.

Een derde interessant effect is wat er gebeurt als u het aantal verbindingen tot nul reduceert, maar toch een directory-item op de inode wijst. Ik laat dat aan jou over om te experimenteren met als je wilt. Het is echter duidelijk dat deze laatste twee beide ertoe leiden dat het bestandssysteem zich in een inconsistente toestand bevindt.


25
2018-04-02 13:08



Op een andere manier kijkend, is het aantal verbindingen niet nul, omdat het openen van een bestand een link toevoegt binnen / proc. - OrangeDog
@OrangeDog, dit gedrag bestaat nog steeds, zelfs als procfs is gedeactiveerd. - Charles Duffy
@ OrangeDog Charles Duffy heeft gelijk. Het bestand verwerkt in / proc doen niet wijzig de inodes en pas het aantal koppelingen aan. - David Hoelzer
/ proc en / sys zijn reflecties van de huidige systeem (kern) status. Alleen acties naar bestanden en mappen selecteren daar verandert de systeemstatus. - Michael Kjörling


Eerdere antwoorden zijn goed, maar ik wil een detail verduidelijken:

rm is niet alleen een commando. Het is een programma dat je kunt vinden in PATH.

Daarom gebeurt er wat gebeurt er als je uitvoert:

  • je belt (als root) rm -rf /
  • exemplaar van programma rm wordt geladen met argumenten in het geheugen -rf en /
  • op basis van dit argumentenprogramma rm start zijn operaties (doorloopt alles in de aangekoppelde / partitie en verwijdert recursief verwijzingen ernaar [sorry voor technische details;)])
  • als het eenmaal is voltooid, wordt de instantie van rm programma is uitgeladen
  • op dit punt zijn de enige dingen in het geheugen de programma's die daar eerder zijn geladen (bijvoorbeeld bash als je een terminal hebt geopend in Ubuntu, Desktop-omgeving, kernel, stuurprogramma's, enz.)
  • als je een andere opdracht probeert te gebruiken (wat in het geval van Linux het een op zichzelf staand programma maakt), zal het mislukken omdat er geen dergelijk programma is gevonden in PATH-locaties (en PATH-locaties bestaan ​​niet meer). Alles wat eenmaal is geladen, wordt echter nog steeds uitgevoerd

Gewoon om te begrijpen hoe het werkt, probeer LAMP te installeren op ubuntu (in Virtualbox), wat script en PHP opcodecache, noem dan dit slechte commando. Verrassend genoeg (als je geluk hebt en je opcode-cache geen php-bestandsverwijdering zal opmerken) kun je nog steeds toegang krijgen tot php-scripts van buiten via apache webserver!

PS: dit kwaadaardige commando loopt zelfs als root niet zal verwijderen everything, het kan sommige kernel-bevoorrechte processen niet verwijderen /proc en kan sommige dingen niet verwijderen /dev apparaten die op uw systeem verschijnen als bestanden. In feite is root niet zo almachtig als we denken, kernel aan de andere kant.

PPS: ook als een tweede gedachte heb je nog steeds bestanden die dat wel waren locked door een ander proces op het moment van verwijdering.


18
2018-04-02 11:45



Op Linux kun je apparaatknooppunten zeker verwijderen als ze als root worden uitgevoerd. Maar ja, je kunt niets verwijderen van /proc omdat het een alleen-lezen bestandssysteem is. Evenzo voor /sys. Ik geloof dat je ook geen mount points kan verwijderen. - Brian
@AlexKey Ik stel voor om te bewerken om duidelijk te maken wat je bedoelt met "niet-kernel ingebed commando" (of om die zin helemaal te vermijden). Het klinkt alsof je zegt dat er opdrachten zijn die je kunt uitvoeren door een shell die rechtstreeks in de kernel wordt geïmplementeerd, zodat ze altijd werken, wat er ook gebeurt. (Wat is, zoals u waarschijnlijk weet, maar veel lezers niet, niet het geval: wanneer u een commando uitvoert zoals cd, dit roept de shell gebouwd met die naam - dat commando is ingebouwd in de shell, niet de kernel.) Bedoel je Alt + SysRq "commands"? - Eliah Kagan
@Brian hangt het af van distro? Ik heb in verschillende distro's gewerkt en als grappig klinkt deze fout meerdere keren gemaakt. Zoals ik me herinnerde na het inspecteren van resten van / er was nog steeds iets in / dev, maar het kan dingen zijn zoals cdrom of floppy ... - Alexey Kamenskiy
@EliahKagan Omdat ik probeerde distro onafhankelijk te blijven, gebruikte ik deze term daarom. Het betekent dat niet op alle systemen cli-opdracht een extern programma betekent. Maar bedankt, voor dat uit te wijzen, zal ik het punt verduidelijken. - Alexey Kamenskiy
@AlexKey Ik geloof dat je dit niet zou kunnen verwijderen /dev/pts omdat het een koppelpunt is. (En ook een alleen-lezen bestandssysteem.) - Brian


Zodra alles is weggevaagd van de harddrives werkt de kernel nog steeds, maar een beetje vastgelopen omdat er geen apparaten en programma's, commando's, enz. Over zijn.

Het besturingssysteem zal niet meer werken.

En het is waar wat Oli zegt, het commando wordt geladen / uitgevoerd in het geheugen en niets zal het stoppen, tenzij je dit proces doodt (natuurlijk, als het kill-commando nog steeds aanwezig is ^^).


1
2018-04-02 09:35



Waarom zou de kernel vastlopen? Het antwoord van MainMa suggereert iets anders en ondersteunt wat ik had verwacht. - MvG
Programma's lopen uit het geheugen, niet uit de harde schijf. De kernel zou niet weten dat er iets mis is tot een herstart. - phyrfox
Nou misschien moet ik de woorden die ik heb gebruikt veranderen, de kernel is min of meer "vast" zonder apparaten, programma's, enz. En als je niet voor de root-console staat, kun je geen slechte dingen doen, zelfs niet op dat moment console, je kunt geen slechte dingen doen. Maar ik zal mijn formulering in mijn antwoord veranderen omdat het misleidend is, daar ben ik het mee eens. - s1mmel


Houd er rekening mee dat als het systeem selinux heeft en selinux in de handhavingsmodus is, het beleid van selinux correct is ingesteld; dan gebeurt er niet veel.

Selinux is verplichte toegangscontrole, wat onder meer betekent dat de root-gebruiker echt niet veel meer macht heeft om het systeem te vernietigen dan enige andere gebruiker op het systeem.

Selinux wordt afgedwongen in de kernel; je zou de kernel moeten compromitteren om er omheen te komen.

Op een goed ontworpen systeem met een goed Selinux-beleid zou root niet veel kunnen doen op het systeem.

De latere herzieningen van Android hebben Selinux alleen maar om deze reden afgedwongen.


0
2018-04-03 02:38