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

200

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.

n0pe
la source
8
C'est drôle que vous ayez posé cette question. Je répondais simplement à une autre question rm -f sur un autre forum et commençais à me souvenir d'un article que j'avais lu il y a quelque temps. Heureusement, je l'ai sauvegardé pour des moments comme celui-ci: LA classique histoire d'horreur Unix. Outre le fait qu'il est intéressant de voir jusqu'où cela ira ... Je pense que c'est un article très bien écrit et une bonne lecture!
akseli
3
Je viens d'essayer sudo rm -rf /sur tinycore / microcore Linux et il semble que le système d'exploitation protège plusieurs répertoires (/ sys et autres) de la suppression.
n0pe
47
J'ai essayé rm -f /bin/rmune fois. Malheureusement, cela a fonctionné et j'ai passé l'heure suivante à récupérer la bonne version de rmGNU Coreutils.
Squircle
17
Attendez une seconde, je vais essayer ...
Martijn Courteaux
38
Je le fais tout le temps au magasin Apple Store
eggie5

Réponses:

188

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.

Ambroz Bizjak
la source
67
Exactement ce que je cherchais. Maintenant, utiliser ce pouvoir pour conquérir le monde.
n0pe
34
+1 surtout --no-preserve-rootparce que ce n'est généralement pas mentionné.
Matěj G.
22
@ MaxMackie, il est intéressant de noter que les pirates informatiques ont très vite constaté que c'était la chose la moins utile qu'ils pouvaient faire pour un utilisateur. Il détruit toutes les données pouvant être utilisées pour réaliser des gains en espèces et empêche le pirate d’exploiter davantage la machine. Comme un chat avec un insecte, vous ne voulez pas le tuer, vous voulez juste jouer avec lui pendant un moment parce que c'est amusant.
zzzzBov
5
Pour répondre à l'autre question du PO, oui, elle va se retirer. Il est tout à fait possible de modifier ou de supprimer un exécutable même si une instance de celui-ci est en cours d'exécution. Il continuera à fonctionner également et ne sera pas affecté par le changement.
thomasrutter
3
Je voudrais mentionner "chmod -R utilisateur: utilisateur *" à /, car il s'agit également d'une erreur récursive et coûteuse. Je l'ai fait une fois, et j'étais arrivé à mi-chemin / à la maison au moment où je pouvais avorter. / bin / boot / etc / dev étaient la propriété. Heureusement, le serveur a continué à fonctionner alors que je passais manuellement les prochaines heures à réinitialiser les droits de propriété à partir d'un système de référence. Cependant, personne d'autre ne pourrait utiliser su ou sudo par la suite. Finalement, nous avons découvert que / bin / su n’avait plus son bit setuid défini. Prenez note pour l’avenir: chowning / bin / su réinitialise son bit setuid!
Andy Lee Robinson
42

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.

Xeoncross
la source
22

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.

PriceChild
la source
7
Je n'ai même pas pensé à l'essayer sur une machine virtuelle. Va essayer maintenant! ooo c'est amusant.
n0pe
40
A tort, écrit la commande sur le terminal du système hôte
slhck
1
Découvrez l'article que j'ai posté. "L'histoire d'horreur Unix classique!"
akseli
1
Je suis au travail en ce moment et je n’ai pas le temps de passer à travers l’installation complète d’une distribution populaire (Ubuntu / Slack / Suse / Fedora). Si quelqu'un d'autre pouvait cloner un fichier de disque de machine virtuelle et l'essayer pour nous, ce serait génial.
n0pe
2
Avec Amazon EC2, il devrait être rapide de lancer une de leurs AMI qui a déjà installé Linux et de tirer ...
David d C e Freitas
11

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é

Bonjour71
la source
1
Oui, je reçois aussi ces erreurs / avertissements. Est-ce que c'est ce que vous pensez?
n0pe
5
/ proc, / sys, parfois / dev, et tous les points de montage sont des propriétés du système d'exploitation et ne peuvent pas être supprimés.
pjc50
1
Comme @ pcj50, il ne s'agit pas littéralement de fichiers sur le disque dur. Par conséquent, les "supprimer" n'a pas de sens.
CarlF
7

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

zwol
la source
4

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] 
jlliagre
la source
2
"soulignant que si on essaye de supprimer" / "récursivement, on finira par essayer de supprimer" .. "et". ", et que tout ce que nous faisons est de permettre à rm de déterminer à l'avance cette information de manière heuristique. ! "- euh, cela n'empêcherait-il pas de supprimer un répertoire? La spécification actuelle ne permet que .. et. dans les arguments de ligne de commande réels, il ne dit rien sur ce que vous "essayez en fin de compte de supprimer"
Random832
1
Pourquoi interdire la suppression de tout répertoire? Le répertoire racine est le seul concerné ici et sa suppression implique évidemment la suppression de "." et "..", quel que soit le répertoire en cours. Le sens commun n'est pas interdit dans l'interprétation standard.
jlliagre
1
Cette ligne d'argumentation est pur génie.
Nate CK
La norme spécifie que rm n'est pas autorisé à continuer si un argument a pour chaîne "." ou ".." comme composant de base. Vous ne pouvez pas enlever /foo/..même si vous n'êtes pas dans /foo. Il ne spécifie pas que vous n'êtes pas autorisé à supprimer le répertoire actuel (par exemple rm -r `pwd`) ou le parent du répertoire actuel.
Random832
2
En effet, j'ai mal compris la déclaration et vous avez raison. Espérons que les types standard ont accepté le comportement plus intelligent comme étant conforme à la norme. Supprimer des parties volumineuses sinon tout le système de fichiers rendrait rapidement le système d'exploitation non conforme à la norme.
Jlliagre
3

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.

CarlF
la source
C'est vrai, parce qu'ils sont chargés en mémoire, n'est-ce pas?
n0pe
Je ne suis pas sûr que ce soit sûr de supposer; le noyau pourrait très bien charger le fichier supprimé en mémoire et le supprimer immédiatement sur le disque, et conserver cette copie en mémoire jusqu'à ce que le fichier soit ouvert (par exemple jusqu'à ce que rm soit en cours d'exécution).
Ambroz Bizjak
Je ne spécule pas. Si un programme est en cours d'exécution, sa suppression ne le supprime pas sur mes machines Linux, du moins. (Remarquez que je n'ai pas testé cela depuis, oh, quelques années.)
CarlF
4
rm va se retirer de la fs - le programme est complètement chargé en mémoire, pas le fichier
warren
4
@MaxMackie: non pas parce qu'ils sont chargés en mémoire, mais parce qu'une référence de fichier ouvert a le même pouvoir qu'un lien physique (c'est-à-dire que si un fichier a au moins un lien dur, il ne sera pas supprimé du disque).
Lie Ryan
1

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.

Anarko_Bizounours
la source
12
"[Pas effacé] uniquement le processus essentiel pour le système d'exploitation" - ne vous inquiétez pas. Contrairement à Windows, Linux effacera n'importe quoi, même si le fichier est critique et utilisé. /boot, /sbin, /etc, /bin, /vmlinuz? Bam, parti. Bonne chance pour démarrer sans ceux-ci - en fait, bonne chance pour ne rien faire une fois la suppression terminée.
Piskvor
Si je me souviens bien, il y a eu des fichiers qui n'ont pas été supprimés et j'ai laissé mon Linux s'exécuter pendant plus de 4 heures. Mais bon, il est bon de savoir ce qui se passe, comme faire un chmod 777 / * -fR;)
Anarko_Bizounours le
3
"chmod 777 / * -fR" - Cela devrait rendre le système très peu sécurisé, bien que très convivial.
Bart van Heukelom
1
@BartvanHeukelom, certains outils effectueront un auto-test rapide ou seront testés par le système pour en vérifier la propriété et les autorisations appropriées et refuser d'agir s'ils sont mal configurés.
Killermist
1
chmod -fR 777 /est nocif car il désactive les bits setuid et setgid.
G-Man
1

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:

Kenorb
la source