In che modo 'rm -rf /' è in grado di cancellare tutti i file nel sistema?

81

Non ho provato questo comando su Ubuntu (per ovvi motivi) quindi non sono sicuro che Ubuntu consentirà la sua esecuzione. Ma è famoso per aver cancellato tutto. Solo per curiosità, cosa succede quando il kernel e /bin vengono cancellati? In che modo rm mantiene uno stack di runtime? In che modo rm riesce a comunicare con il file system e completare la cancellazione? Come comunica con l'hardware?

    
posta Muye 02.04.2015 - 10:13

6 risposte

77

Non importa che /bin/rm sia cancellato. Viene eseguito solo una volta e a quel punto viene caricato in memoria, come tutto il resto richiesto per continuare a inviare le eliminazioni al filesystem e al disco.

Barra laterale / Aggiornamento: alla risposta di David Hoelzer (e menzionata nei commenti), l'inode in cui il% del linkato in% co_de utilizzato per puntare rimarrà fino a quando non viene completato /bin/rm (perché Linux mantiene uno stato aperto) ma tale fatto è irrilevante; lo stato del disco non ha alcuna importanza.

Il file binario viene caricato in memoria prima dell'esecuzione. Anche se fosse possibile distruggere manualmente i dati del disco rm , ciò non influirebbe o impedirà il completamento dell'eliminazione (supponendo che altrimenti non sia reso disponibile il disco).

Non hai idea di cosa siano un inode o un hardlink? Questa è la risposta in cui l'ho elaborata.

Comunque, questo è anche il motivo per cui puoi cancellare il pacchetto per il corrente kernel senza l'implosione del computer. Finché si installa una versione diversa, sarà in grado di avviarsi.

Ancora, questo funziona perché rm viene chiamato solo una volta. Il seguente sarebbe fallito dopo che rm è morto perché lo chiama una volta per ogni nome file:

find / -exec rm {} \;

Detto questo, anche /bin/rm e find / -exec rm -rf {} + potrebbero fallire entrambi perché entrambi hanno limiti di argomenti, il che significa che eliminerebbero solo un numero di file prima di essere richiamati. A un certo punto del percorso, find / -print0 | xargs -0 rm -rf potrebbe scadere ( e essere rilasciati) prima che il resto dei file venisse cancellato. Tuttavia non è garantito. Se /bin/rm era l'ultima directory inserita, questi metodi potrebbero funzionare.

    
risposta data Oli 02.04.2015 - 10:26
56
% Bl0ck_qu0te%

L'ho fatto. rm -rf / --no-preserve-root era in esecuzione in una sessione root aperta direttamente sulla macchina, mentre ero anche connesso tramite ssh da un'altra macchina, usando anche l'account root.

Ciò che accade è che inizi a ricevere molti di messaggi come:

% Bl0ck_qu0te%

o

% Bl0ck_qu0te%

Sorprendentemente,laconnessionesshèrimastaapertafinoallafinedell'operazione.Èsoloquandohochiusolaconnessioneehoprovatoariaprirloperchéèapparsounerrore:

%Bl0ck_qu0te%

Sullamacchinarimangonoquattrodirectory:

  • /dev . Qui sono archiviati i file del dispositivo.
  • /proc - filesystem in-memory creato dal kernel.
  • /run , un percorso di file system standardizzato per i demoni.
  • /sys . Ciò ti consente di ottenere informazioni sul sistema e i suoi componenti.

Ciò significa che non c'è rimasto molto e non c'è molto da fare lì. Non puoi ls (sebbene quando usi la Tab , i nomi delle directory e dei file siano ancora visualizzati). Puoi cd in diverse directory e anche echo stuff, ma comandi come cat non sono più disponibili.

Neanche sudo .

shutdown -h now e reboot sono scomparsi, quindi l'unica opzione sembra spegnere la macchina manualmente. Il logout ( exit ) non funziona, anche se mostra un bel testo di "disconnessione".

Una volta provato a riavviare la macchina, ti viene presentato un bel errore GRUB 15, quindi non succede nulla, a quel punto potresti iniziare a pensare che il tuo rm potrebbe aver fatto qualcosa di male al tuo sistema.

Puoifarloanche

No,aspetta,nonfarlosultuocomputer!

Quellochepuoifareinveceèeseguireunamacchinavirtuale.Lemacchinevirtualihannoilvantaggiodirenderelasperimentazionedavverofacile.DatochestaiusandoUbuntu,potrestiessereinteressato vmbuilder . Questo è uno strumento che consente di distribuire macchine virtuali in pochi minuti (la documentazione ufficiale afferma che può essere eseguita "in circa un minuto", ma il tempo effettivo, anche su hardware veloce, è di circa 2-3 minuti .

Una volta terminata la distribuzione, hai un ambiente con cui puoi giocare. Se si finisce per distruggerlo, non importa: si distribuisce nuovamente la macchina e due minuti dopo è possibile continuare.

Se usi software come VMWare, potresti essere interessato anche a istantanee (nota che il VMWare Player gratuito non ha questa caratteristica, devi acquistare VMware Workstation). Nota che Hyper-V è gratuito e supporta le istantanee (ma devi eseguire Windows).

Il vantaggio delle istantanee è che puoi prenderne uno in pochi millisecondi. Il ritorno a uno snapshot richiede più tempo, ma spesso è questione di secondi. Ciò rende la sperimentazione ancora più facile e veloce.

Questa sperimentazione non è limitata al sistema operativo stesso. Puoi fare tutto ciò che riguarda il software. Hai un'applicazione sospetta? Provalo in una VM: se è un virus, non farà alcun danno. Vuoi testare un'operazione su un database, dato che potrebbe influenzare l'ambiente? Provalo in una VM.

Che cosa succede se l'hai fatto su una macchina reale non di prova?

Le cose brutte accadono. Tieni presente che rm ti protegge da te stesso: rm -rf / non funzionerà: devi utilizzare --no-preserve-root . Eppure, cosa succede se hai effettivamente realizzato, per errore, rimuovere tutto?

rm solo scollega i file , ma i dati sono ancora lì, sul tuo disco rigido. Ciò consente di ripristinarlo in un secondo momento (motivo per cui non dovresti semplicemente gettare via i tuoi dischi rigidi con dati sensibili quando non funzionano più).

Ciò significa che devi solo avere un PC di riserva con un enclosure per disco rigido per recuperare quasi tutti tutti i file. L'importante è evitare di scrivere qualcosa sul disco rigido per il recupero: i dati scritti sovrascriveranno i file non collegati.

Come notato da l'articolo nel commento di 200_success , se agisci in modo intelligente, puoi riavviare la macchina anche senza un PC di riserva. Se ti interessano solo i dati, non mi preoccuperei di recuperarli: il ripristino con un PC di riserva è molto più semplice.

    
risposta data Arseni Mourzenko 02.04.2015 - 20:06
25

Il motivo è che il livello di denominazione dei file (ciò che vedi con ls ) è in realtà solo per tua comodità. Il driver del file system e il kernel si preoccupano solo di cosa sia l'inode. Quando un file viene referenziato per nome, viene immediatamente tradotto nell'inode che contiene tutti i metadati incluse le autorizzazioni, i blocchi di dati sul disco, l'ID del proprietario, l'ID del gruppo e il conteggio dei collegamenti.

Il conteggio dei collegamenti è ciò che conta davvero qui. Quando si elimina un file su un sistema UNIX, la chiamata di sistema effettiva è unlink . Quello che sta accadendo sotto il cofano è che il conteggio dei collegamenti (il numero di nomi di file nel livello di denominazione dei file) che punta a quell'inode viene decrementato. Il file system sa che un file viene cancellato quando il conteggio dei collegamenti raggiunge lo zero.

Quando un file viene eliminato da rm , modificherà anche il file di directory (sì, è solo un file che contiene il nome del file e l'inode oltre ad alcuni altri bit che non sono importanti per questa risposta). Tuttavia, è lo scollegamento che libera le risorse del disco.

Questo porta ad alcuni altri effetti interessanti. Innanzitutto, è possibile avere un file aperto il cui conteggio dei collegamenti è zero. Ciò accade quando rm -rf / elimina la voce per /bin/rm . Il file è aperto (c'è un handle di file) ma l'inode è marcato cancellato (link count = 0). Le risorse del disco non verranno rilasciate e riutilizzate fino alla chiusura dell'impugnatura del file.

Un altro effetto interessante è ciò che accade quando si ha un inode con un conteggio di link maggiore di zero ma nulla nel livello di denominazione del file che punta ad esso. Questo è, in un certo senso, un file molto ben nascosto :). Per accedervi bisognerebbe usare qualcosa di basso livello per farvi riferimento per numero di inode piuttosto che per nome (perché non ce n'è uno) o modificare una voce di directory per puntare sull'inode usando un editor esadecimale.

Un terzo effetto interessante è ciò che accade se riduci il conteggio dei collegamenti a zero ma puntando comunque una voce di directory sull'inode. Lo lascerò a te per sperimentare se vuoi. Chiaramente, però, questi ultimi due portano entrambi al file system in uno stato incoerente.

    
risposta data David Hoelzer 02.04.2015 - 15:08
18

Le risposte precedenti sono buone, ma voglio chiarire un dettaglio:

rm non è solo un comando. È un programma che si trova in PATH .

Quindi ciò che accade quando esegui sta seguendo:

  • chiami (come root) rm -rf /
  • istanza del programma rm è caricata in memoria con argomenti -rf e /
  • in base a questi argomenti il programma rm inizia le sue operazioni (passando tutto in mount / partizione e rimuovendo in modo ricorsivo i riferimenti ad esso [sorry per tecnicismi;]])
  • una volta terminato, l'istanza del programma rm viene scaricata
  • a questo punto le uniche cose in memoria sono i programmi che sono stati caricati in precedenza (ad es. bash se hai un terminale aperto in Ubuntu, ambiente desktop, kernel, driver ecc.)
  • se si tenta di chiamare qualsiasi altro comando (che nel caso di Linux lo rende un programma autonomo), fallirà perché non esiste un tale programma trovato nei percorsi PATH (e le posizioni PATH non esistono più). Tuttavia, tutto ciò che viene caricato verrà eseguito ancora

Solo per capire come funziona prova a installare LAMP su ubuntu (in Virtualbox), qualche script e cache opcode PHP, quindi chiama questo comando male. Sorprendentemente (se sei abbastanza fortunato e la tua cache dell'opcode non noterà la cancellazione del file php) potrai comunque accedere agli script php dall'esterno tramite il server web Apache!

PS: questo comando malvagio funzionava anche come root, non elimina everything , non può cancellare alcuni processi con privilegi del kernel da /proc e non può cancellare parte di roba da /dev dispositivi che appaiono sul tuo sistema come file. In effetti, root non è onnipotente come pensiamo, il kernel invece è.

PPS: anche se pensiamo che avrai ancora file locked con un altro processo al momento del tentativo di eliminazione.

    
risposta data Alexey Kamenskiy 02.04.2015 - 13:45
1

Una volta che tutto è stato cancellato dagli harddrive, il kernel funziona ancora, ma rimane bloccato perché non ci sono dispositivi e programmi, comandi, ecc. rimasti.

Il sistema operativo non funzionerà più.

Ed è vero ciò che dice Oli, il comando viene caricato / eseguito in memoria e nulla lo fermerà a meno che non si uccida questo processo (ovviamente, se il comando kill è ancora presente ^^).

    
risposta data s1mmel 02.04.2015 - 11:35
0

Si prega di essere consapevoli che se il sistema ha selinux e selinux è in modalità enforcing, e le politiche di selinux sono impostate correttamente; allora non succederà molto.

Selinux è un controllo di accesso obbligatorio, il che significa, tra le tante cose, che l'utente root non ha davvero molto più potere di distruggere il sistema di qualsiasi altro utente sul sistema.

Selinux è applicato nel kernel; dovresti compromettere il kernel per aggirarlo.

Su un sistema ben progettato con buone politiche Selinux, root non sarebbe in grado di fare molto sul sistema.

Le revisioni successive di Android prevedono l'applicazione forzata di Selinux proprio per questo motivo.

    
risposta data Mark Allyn 03.04.2015 - 04:38

Leggi altre domande sui tag