Je me suis souvent demandé jusqu'où irait le système si vous exécutiez rm -rf /
. Je doute que le système d'exploitation puisse s'effacer lui-même (?)
Question bonus : Une fois la commande exécutée, rm
sera-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 définis, rm supprimera tous les bits physiques de données du disque. Cependant, j'ai rencontré des problèmes lorsque j'utilisais une version de rm autre que la version 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 la semaine destinée au super utilisateur.
Lisez l’entrée de blog du 7 juillet 2011 ou soumettez votre propre question de la semaine.
Si vous avez rm
de GNU coreutils (très probablement s'il s'agit d'une distribution Linux normale), rm -rf /
sera refusé par la protection intégrée (selon la page de manuel et Wikipedia, vous n'avez pas essayé cela).
Vous pouvez remplacer cette protection avec --no-preserve-root
. rm
supprimera alors 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 tels que /proc
et /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 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.
Points bonus si vous pouvez nommer les processus au moment où ils commencent à mourir.
Configurez un VM et essayez 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 de manière plus visible. (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 restauration, 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 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: impossible de supprimer '/ proc/kallsyms': opération non autorisée
rm: impossible de supprimer '/ proc/dma': opération non autoriséeSNIP 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: impossible de supprimer '/ tmp': périphérique ou ressource occupé
rm: impossible de supprimer '/': périphérique ou ressource occupé
Je me souviens que alt.sysadmin.recovery
avait été mâché il y a bien longtemps, alors que /proc
n'existait pas, et /dev
était simplement un répertoire contenant des entrées pour de nombreux inodes inhabituels ...
... mais sur certaines variantes d’Unix (je me souviens bien, c’est HP-UX, mais cela pourrait être totalement faux), vous pourriez ne pas supprimer la dernière entrée de répertoire d’un programme courait. (Bibliothèques partagées? Qu'est-ce que c'est?)
Sur de tels systèmes, si vous en démarriez un en mode maintenance (de sorte que rien ne fonctionnait sauf votre Shell, pas même init
, et aucun système de fichiers secondaire n’était monté) et que exec /bin/rm -rf /
, vous restiez avec un système de fichiers racine complètement vide sauf que /bin
et /bin/rm
survivraient.
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é qu'il enfreignait la norme POSIX:
Protection "rm -rf /
" 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.
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 commande rm
serait supprimée avec elle ainsi que toute autre commande standard dans /bin
et d'autres dossiers.
Voici le test simple que j'ai effectué dans Linux Ubuntu 15.04 en utilisant VM.
Initialiser la machine virtuelle via vagrant
:
vagrant init ubuntu/vivid64 && vagrant up --provider virtualbox && vagrant ssh
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
Alors essayons --no-preserve-root
. Vérifiez toujours que vous êtes connecté à la machine virtuelle (pour que vous ayez vagrant@vagrant-ubuntu-vivid-64:~$
), puis lancez-le (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 revient à l'invite du shell comme si rien ne s'était passé, mais vous ne pouvez plus exécuter aucune commande, à part quelques-unes des fonctions intégrées et 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 a pratiquement tout supprimé, y compris rm
, ls
et toutes les autres commandes, mais vous êtes toujours connecté. Certains dossiers spéciaux non supprimés, tels que certains périphériques de /dev
, /proc
ou /sys
, ne sont pas des répertoires/fichiers normaux, mais son pseudo système de fichiers fournit des interfaces de traitement et des données du noyau.
Si vous n'avez pas Vagrant ou Linux, vous pouvez jouer avec des émulateurs JavaScript Linux x86 .
Si vous êtes intéressé par les possibilités de récupérer d'un tel désastre, vérifiez:
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.