Jusqu'où irez-vous avec une commande 'rm -rf /'?

Je me suis souvent demandé jusqu'où irait le système si vous couriez rm -rf /. Je doute que le système d'exploitation puisse s'effacer lui-même (?)

Question bonus : après que la commande a été exécutée, sera rm-t-il supprimé?

Mise à jour: J'ai testé cela dans quelques distributions Unix principales utilisant VirtualBox et les réponses décrivent exactement ce qui se passe. Si les paramètres corrects sont fournis, rm supprimera tous les bits physiques de données sur le disque. Cependant, j'ai rencontré des problèmes lorsque j'utilisais une version de rm autre que celle de GNU. Par exemple, je pense que BusyBox a sa propre version et ne vous permet pas de supprimer autant que vous le pouvez potentiellement.

Cette question était une question de super utilisateur de la semaine .
Lisez l' entrée de blog du 7 juillet 2011 pour plus de détails ou soumettez votre propre question de la semaine.

Si vous rmutilisez des coreutils GNU (le plus probablement si c'est une distribution Linux normale), rm -rf /la protection intégrée refusera (selon la page de manuel et Wikipedia, je n'ai pas essayé cela).

Vous pouvez remplacer cette protection avec --no-preserve-root. rmsupprimera ensuite tout ce qui est possible sans s’arrêter après avoir tenté de supprimer chaque fichier. Bien sûr, cela ne supprimera pas les systèmes de fichiers virtuels comme /procet /sys, mais ce n'est pas pertinent, cela supprimera tout sur votre disque.

Une fois la commande terminée, votre disque sera vidé, y compris le système d'exploitation. Le noyau et les processus actuels continueront de s'exécuter à partir de la mémoire, mais de nombreux processus mourront car ils ne pourront pas accéder à certains fichiers. Le système d'exploitation ne pourra pas démarrer la prochaine fois.

Pour ceux qui aiment faire ce genre de choses visuellement tout en écoutant de la musique techno.

Exécution de rmrf sur Linux (vidéo)

Points bonus si vous pouvez nommer les processus au moment où ils commencent à mourir.

Mettre en place une VM et essayer de vous amuser?

Cela ira assez loin ... si vous utilisez une interface graphique, vous aurez peut-être du plaisir à constater que les choses se dégradent plus visiblement. (les icônes sur les menus cessent de se charger, etc.)

Si vous le laissez partir, le système d'exploitation sera quasiment au-delà de la récupération, mais vous pourrez peut-être récupérer des données facilement.

De toute façon, vous voudrez faire une réinstallation du système d'exploitation.

Eh bien, l'essayer sur http://bellard.org/jslinux/ produit:

rm: impossible de supprimer '/ dev / pts': périphérique ou ressource occupé
rm: impossible de supprimer '/ dev': répertoire non vide
rm: impossible de supprimer '/ proc / swaps': opération non autorisée
rm: can 'not remove' / proc / kallsyms ': opération non autorisée
rm: impossible de supprimer' / proc / dma ': opération non autorisée

SNIP 881 entrées

rm: impossible de supprimer '/ proc / 149 / oom_adj': autorisation refusée
rm: impossible de supprimer '/ proc / 149': opération non autorisée
rm: impossible de supprimer '/ proc': périphérique ou ressource occupé
rm: ne peut pas supprimer '/ tmp': périphérique ou ressource occupé
rm: ne peut pas supprimer '/': périphérique ou ressource occupé

Je me souviens de cela alt.sysadmin.recovery, jadis, quand il n’existait rien /proc, et qu’il /devs’agissait simplement d’un répertoire contenant des entrées pour un tas d’inodes inhabituels ...

... mais sur certaines variantes d'Unix (si je me souviens bien, c'est HP-UX, mais cela pourrait être totalement faux), vous ne pouviez pas supprimer la dernière entrée de répertoire d'un programme en cours d'exécution. (Bibliothèques partagées? Qu'est-ce que c'est?)

Sur ces systèmes, si vous avez commencé un en mode de maintenance (donc rien ne fonctionnait , mais votre coquille, même pas init, et aucun système de fichiers secondaires ont été montés) et ne exec /bin/rm -rf /, vous retrouverez avec un système de fichiers racine complètement vide , sauf que /binet /bin/rmserait survivre.

Les habitants du monastère effrayant du diable ont estimé que cela était approprié et approprié.

rm -rf / ne devrait pas être autorisé sur les implémentations récentes car il a été suggéré que cela violait la norme POSIX:

" rm -rf /" protection sur le blog Oracle

Quoi qu’il en soit, au final, les spécifications ont été modifiées et Solaris 10 dispose (depuis la version 36) d’une version de / usr / bin / rm (/ bin est un lien symbolique vers / usr / bin sous Solaris) et / usr / xpg4 / bin / rm qui se comporte ainsi:

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

Un point que je n’ai vu n’avait pas été fait par qui que ce soit: les fichiers actuellement ouverts (par exemple, rm lui-même), même s'ils ont été supprimés, ne disparaîtront pas du lecteur tant qu’ils ne seront pas fermés.

Pour l'avoir essayé une fois (sur un serveur qui me fait chier), connecté en tant que root, en terminal, vous perdrez presque tout. La seule chose qui ne sera pas effacée sera seulement le processus qui était essentiel pour le système d'exploitation.

Jusqu'où vous pouvez aller, cela dépend essentiellement des distributions Unix / Linux spécifiques.

Mais pour répondre à votre question de base, oui - la rmcommande serait supprimée avec elle, ainsi que toute autre commande standard dans les /binautres dossiers.

Voici le test simple que j'ai effectué dans Linux Ubuntu 15.04 en utilisant VM.

1. Initialiser la machine virtuelle via vagrant:

   vagrant init ubuntu/vivid64 && vagrant up --provider virtualbox && vagrant ssh
   

2. Ensuite, lorsque vous essayez de supprimer tous les fichiers de manière standard, cela ne vous permet pas:

   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. Alors essayons --no-preserve-root. Vérifiez toujours que vous êtes connecté à la machine virtuelle (afin que vous ayez vagrant@vagrant-ubuntu-vivid-64:~$), puis exécutez (n'essayez pas cela à la maison):

   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
   

   Après cela, il retourne à l'invite du shell comme si rien ne s'était passé, mais vous ne pouvez plus exécuter aucune commande, mis à part quelques fonctions intégrées kill, de sorte que vous puissiez terminer votre travail et tuer votre session :)

   Par exemple:

   $ 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.
   

Donc , il à peu près tout enlevé, y compris rm, lset toutes les autres commandes, mais vous êtes connecté. Certains dossiers spéciaux n'ont pas été supprimés, tels que certains périphériques /dev, /procou /sysne sont pas des répertoires / fichiers normaux, mais c'est un pseudo système de fichiers fournissant des interfaces pour traiter les données du noyau.

Si vous n'avez pas Vagrant ou Linux, vous pouvez jouer avec certains émulateurs JavaScript Linux x86 .

Si vous êtes intéressé par les possibilités de récupérer d'un tel désastre, vérifiez:

• Erreur du lundi matin: sudo rm -rf --no-conserve-root /