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

Non ho provato questo comando su Ubuntu (per ovvi motivi), quindi non sono sicuro che Ubuntu ne consentirà l'esecuzione. Ma è famoso per aver eliminato tutto. Solo per curiosità, cosa succede quando il kernel e /binvengono eliminati? Come rmmantiene uno stack di runtime? Come rmriesce a comunicare con il file system e completare la cancellazione? Come comunica con l'hardware?

Non importa che /bin/rmvenga eliminato. Viene eseguito solo una volta e a quel punto è tutto caricato in memoria, così come tutto il resto necessario per continuare a inviare cancellazioni al filesystem e al disco.

Sidebar / Update: Per la risposta di David Hoelzer (e citato nei commenti), l'inode il collegamento reale /bin/rmutilizzato per indicare sarebbe rimasto fino a quando rmfinito (perché Linux tiene in uno stato aperto) , ma questo fatto è irrilevante; lo stato del disco non ha alcuna importanza.

Il binario viene caricato in memoria prima di essere eseguito. Anche se potresti distruggere manualmente i rmdati del disco, ciò non influirebbe o impedirebbe il completamento dell'eliminazione (supponendo che altrimenti non renderai il disco non disponibile).

Non hai idea di cosa siano un inode o un hardlink? Questa è la risposta dove l'ho elaborato.

Comunque, questo è anche il motivo per cui è possibile eliminare il pacchetto per il kernel corrente senza che il computer implichi. Finché installi una versione diversa, sarà in grado di avviarsi.

Ancora una volta, questo funziona perché rmviene chiamato solo una volta. Di seguito avrebbe fallire dopo /bin/rmmorto perché richiede una volta per ogni nome di file:

find / -exec rm {} \;

Detto questo, find / -exec rm -rf {} +e find / -print0 | xargs -0 rm -rfprobabilmente entrambi fallirebbero perché entrambi hanno limiti di argomento, il che significa che eliminerebbero solo un numero di file prima di essere richiamati. Ad un certo punto del viaggio, /bin/rmpotrebbe scadere ( ed essere rilasciato) prima che il resto dei file venisse eliminato. Non è garantito però. Se /bin/fosse stata immessa l'ultima directory, questi metodi potrebbero funzionare.

Non ho provato questo comando su Ubuntu (per ovvi motivi), quindi non sono sicuro che Ubuntu ne consentirà l'esecuzione.

L'ho fatto. rm -rf / --no-preserve-rootera in esecuzione in una sessione di root aperta direttamente sulla macchina, mentre ero collegato anche sshda un'altra macchina, usando anche l'account di root.

Quello che succede è che inizi a ricevere molti messaggi come:

rm: impossibile rimuovere '/ ...': operazione non consentita

o:

rm: impossibile rimuovere '/ ...': dispositivo o risorsa occupata

Sorprendentemente, la sshconnessione è rimasta aperta fino alla fine dell'operazione. È solo quando ho chiuso la connessione e ho provato a riaprirlo che è apparso un errore:

Lettura dal socket non riuscita: connessione reimpostata dal peer

Sulla macchina rimangono quattro directory:

• /dev. Qui sono memorizzati i file del dispositivo.
• /proc—In file system in memoria creato dal kernel.
• /run, una posizione standardizzata del file system per i demoni.
• /sys. Ciò consente di ottenere informazioni sul sistema e sui suoi componenti.

Ciò significa che non è rimasto molto, e non c'è molto da fare lì. Non puoi ls(anche se durante l'utilizzo Tab, i nomi delle directory e dei file sono ancora visualizzati). Puoi cdin diverse directory, e anche echocose, ma comandi come catnon sono più disponibili.

Non c'è sudoneanche.

shutdown -h nowe anche rebootscomparso, quindi l'unica opzione sembra abbassare manualmente la macchina. Logout ( exit) non funziona, anche se mostra un bel testo "logout".

Una volta che provi a riavviare il computer, ti viene presentato un bel errore GRUB 15 e quindi non succede nulla, a quel punto potresti iniziare a pensare che rmpotresti aver fatto qualcosa di male al tuo sistema.

Puoi farlo anche tu

No, aspetta, non farlo sulla tua macchina!

Quello che puoi fare invece è eseguire una macchina virtuale . Le VM hanno il vantaggio di rendere la sperimentazione davvero semplice. Dato che stai usando Ubuntu, potresti essere interessato da vmbuilder . Questo è uno strumento che ti 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 due-tre minuti .

Al termine della distribuzione, hai un ambiente con cui puoi giocare. Se finisci per distruggerlo, non importa: dispieghi di nuovo la macchina e due minuti dopo puoi continuare.

Se usi software come VMWare, potresti anche essere interessato alle istantanee ( tieni presente che il VMWare Player gratuito non ha questa funzione; devi acquistare VMware Workstation). Si noti che Hyper-V è gratuito e supporta le istantanee (ma è necessario eseguire Windows).

Il vantaggio degli snapshot è che puoi prenderne uno in pochi millisecondi. Il rollback a un'istantanea richiede più tempo, ma spesso è una questione di secondi. Questo rende la sperimentazione ancora più semplice e veloce.

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

E se lo facessi su una macchina reale, senza test?

Succedono cose brutte. Nota che rmti protegge da te stesso: rm -rf /non funzionerà: devi usarlo --no-preserve-root. Tuttavia, cosa succederebbe se riuscissi effettivamente a rimuovere tutto per errore?

rmscollega solo i file , ma i dati sono ancora presenti sul disco rigido. Ciò consente di ripristinarlo in un secondo momento (motivo per cui non dovresti semplicemente eliminare i tuoi dischi rigidi con dati sensibili quando non funzionano più).

Ciò significa che devi solo avere un PC di riserva con un alloggiamento del disco rigido per recuperare effettivamente quasi tutti i file. L'importante è evitare di scrivere qualsiasi cosa sul disco rigido da recuperare: i dati scritti sovrascriveranno i file non collegati.

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

Il motivo è che il livello di denominazione dei file (quello che vedi con ls) è davvero solo per tua comodità. Il driver del file system e il kernel si preoccupano solo dell'inode. Quando un file viene referenziato per nome, viene immediatamente tradotto nell'inode che contiene tutti i metadati inclusi i permessi, 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 è un unlink. Ciò che accade 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 è diminuito. Il file system sa che un file viene eliminato quando il conteggio dei collegamenti raggiunge lo zero.

Quando un file viene eliminato rm, modificherà anche il file della 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 effettivamente le risorse del disco.

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

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

Un terzo effetto interessante è ciò che accade se si riduce il conteggio dei collegamenti a zero ma si punta comunque una voce di directory sull'inode. Lascio a te quello di sperimentare se vuoi. Chiaramente, però, questi ultimi due portano entrambi in uno stato incoerente nel file system.

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

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

Pertanto, ciò che accade quando si esegue è il seguente:

• tu chiami (come root) rm -rf /
• l'istanza del programma rmviene caricata in memoria con argomenti -rfe/
• sulla base di questi argomenti, il programma rminizia le sue operazioni (esaminando tutto in montato / partizione e rimuovendo ricorsivamente i riferimenti ad esso [scusate per tecnicità;)])
• una volta terminato, l'istanza del rmprogramma viene scaricata
• a questo punto le uniche cose in memoria sono i programmi che erano stati caricati lì precedentemente (ad es. bash se hai un terminale aperto in Ubuntu, ambiente desktop, kernel, driver ecc.)
• se provi a chiamare un altro comando (che nel caso di Linux lo rende un programma autonomo), fallirà perché non esiste un programma simile nelle posizioni PATH (e le posizioni PATH non esistono più). Tuttavia, tutto una volta caricato continuerà a funzionare

Solo per capire come funziona prova a installare LAMP su Ubuntu (in Virtualbox), alcuni script e cache opcode PHP, quindi chiama questo comando malvagio. Sorprendentemente (se sei abbastanza fortunato e la tua cache opcode non noterà la cancellazione del file php) puoi comunque accedere agli script php dall'esterno tramite il webserver apache!

PS: questo comando malvagio è stato eseguito anche come root non eliminerà everything, non può eliminare alcuni processi privilegiati del kernel /proce non può eliminare alcune cose dai /devdispositivi che appaiono sul tuo sistema come file. In realtà, root non è così onnipotente come pensiamo, il kernel invece è.

PPS: Anche come secondo pensiero avrai anche dei file che erano stati lockedsottoposti a un altro processo al momento del tentativo di eliminazione.

Una volta che tutto è stato cancellato dai dischi rigidi, il kernel funziona ancora ma in qualche modo si blocca perché non ci sono dispositivi e programmi, comandi, ecc. Rimasti.

Il sistema operativo non funzionerà più.

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

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

Selinux è un controllo di accesso obbligatorio, il che significa, tra le altre 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 di Selinux, root non sarebbe in grado di fare molto sul sistema.

Le successive revisioni di Android hanno fatto applicare Selinux proprio per questo motivo.