Question Comment 'rm -rf /' est-il capable de supprimer tous les fichiers du système?


Je n'ai pas essayé cette commande sur Ubuntu (pour des raisons évidentes), je ne suis donc pas sûr si Ubuntu autorisera son exécution. Mais c'est célèbre pour tout supprimer. Juste par curiosité, que se passe-t-il lorsque le noyau et /bin sont supprimés? Comment fait rm maintenir une pile de temps d'exécution? Comment fait rm réussir à communiquer avec le système de fichiers et à effectuer la suppression? Comment communique-t-elle avec le matériel?


80
2018-04-02 08:13


origine


rm -rf / ne supprime rien sans --no-preserve-root. - muru
Ma toute première expérience avec Linux consistait à créer un Ubuntu vm pour pouvoir le "rm -rf /". Je vous recommande d'essayer ceci. Il est assez rapide à configurer, il garde votre hôte en sécurité et il est très amusant de voir les différentes parties de l'OS s'effondrer sous vos yeux. Très satisfaisant. - DJMcMayhem
Cela me rappelle mon rapport de bogue préféré sous-estimé: bugzilla.redhat.com/show_bug.cgi?id=1202858   "Résultats attendus: Squid est redémarré. Résultats réels: tous les fichiers sont supprimés sur la machine."
Vous devriez lire Légende de récupération sous Unix. Tant que vous êtes toujours connecté à un shell, le système n'est pas complètement mort! - 200_success
@gerrit J'ai fait. :) - muru


Réponses:


Cela n'a pas d'importance /bin/rm est supprimé. Il n'est exécuté qu'une seule fois et à ce stade, tout est chargé en mémoire, comme tout ce qui est nécessaire pour continuer à envoyer des suppressions au système de fichiers et au disque.


Barre latérale / mise à jour: Par Réponse de David Hoelzer (et mentionné dans les commentaires), l'inode le lien dur /bin/rm l'habitude de pointer resterait jusqu'à ce que rm terminé (parce que Linux est ouvert) mais ce fait n'est pas pertinent; l'état du disque n'a aucune importance.

Le binaire est chargé en mémoire avant d'être exécuté. Même si vous pouviez détruire manuellement le rm données disque, cela n'affecterait pas ou n'empêcherait pas la suppression (en supposant que vous ne rendiez pas le disque indisponible autrement).

Aucune idée de ce qu'est un inode ou un hardlink? C'est la réponse où je l'ai élaboré.


En tout cas, c'est aussi pourquoi vous pouvez supprimer le paquet pour le actuel noyau sans que l'ordinateur n'implose. Tant que vous installerez une version différente, vous pourrez démarrer.

Encore une fois, cela fonctionne parce que rm est appelé seulement une fois. Le suivant aurait échouer après /bin/rm est mort parce qu'il appelle une fois pour chaque nom de fichier:

find / -exec rm {} \;

Cela dit, find / -exec rm -rf {} + et find / -print0 | xargs -0 rm -rf aurait également probablement échoué parce qu'ils ont tous deux des limites d'argument, ce qui signifie qu'ils ne supprimeraient qu'un certain nombre de fichiers avant d'être appelés à nouveau. À un moment donné du voyage, /bin/rm pourrait expirer (et être libéré) avant que le reste des fichiers aient été supprimés. Ce n'est pas garanti si. Si /bin/ Si le dernier répertoire était entré, ces méthodes pourrait travail.


76
2018-04-02 08:26



Comme l'explique @DavidHoelzer, les fichiers non liés ne doivent pas nécessairement être en mémoire pour continuer à fonctionner. Le noyau sait qu'il existe un descripteur de fichier ouvert. Il conserve donc les données du fichier pour répondre à toutes les demandes (y compris les pages-ins) jusqu'à la fermeture du dernier descripteur. - Andrew Medico
@Desty, non, ça ne réussirait pas, tant que /bin/rm n'est pas assez proche pour être la fin du dernier lot; -exec ... {} + (la barre oblique inverse est inutile) entraîne toujours plusieurs exécutions; pas un par fichier, mais un par lot en fonction du nombre d’arguments pouvant être contenus dans ARG_MAX. - Charles Duffy
@ Oli, ce n'est pas une question de pagination; Les compteurs de référence sont liés à l'inode, et non à l'entrée du répertoire, et un descripteur de fichier ouvert est considéré comme une référence (identique à un lien physique), ce qui empêche la libération de l'inode. La taille du fichier n'est pas un facteur, et cela se produit même s'il n'y a pas d'espace de swap (donc pas de pagination). - Charles Duffy
@CharlesDuffy Que vous ayez ou non un espace de swap, la pagination sera utilisée pour tous les fichiers mappés en mémoire. Cela inclut tous les exécutables et les bibliothèques. En fait, l’absence d’espace d’échange peut en fait signifier plus de pagination pour les fichiers mappés en mémoire. - kasperd
@CharlesDuffy Oui, la taille est en effet sans importance. Le mappage de mémoire d'un fichier ne provoque pas le chargement du contenu du fichier tant qu'il n'est pas accessible. Si nécessaire, la mémoire utilisée pour charger les parties du fichier auxquelles vous avez accédé peut être libérée, après quoi elle sera chargée à partir du fichier si vous y accédez à nouveau. Le fichier doit donc rester sur le système de fichiers tant qu'il est mappé, et cela se comporte de la même façon pour un fichier d'une page que pour un fichier suffisamment grand pour couvrir tout l'espace d'adressage. (Les détails sont un peu plus compliqués pour les mappages de copie en écriture nécessaires à la liaison dynamique.) - kasperd


Je n'ai pas essayé cette commande sur Ubuntu (pour des raisons évidentes), je ne suis donc pas sûr si Ubuntu autorisera son exécution.

J'ai fait. rm -rf / --no-preserve-root était en cours d'exécution dans une session racine ouverte directement sur la machine, alors que j'étais également connecté via ssh à partir d'une autre machine, en utilisant également le compte root.

Qu'est-ce qui se passe est que vous commencez à obtenir beaucoup des messages comme:

rm: impossible de supprimer '/ ...': opération non autorisée

ou:

rm: impossible de supprimer '/ ...': périphérique ou ressource occupé

enter image description here

Étonnamment, ssh la connexion est restée ouverte jusqu'à la fin de l'opération. C'est seulement quand j'ai fermé la connexion et essayé de la rouvrir qu'une erreur est apparue:

Échec de la lecture du socket: connexion réinitialisée par l'homologue

Sur la machine, il reste quatre répertoires:

  • /dev. C'est là que sont stockés les fichiers de périphérique.
  • /proc—Dans le système de fichiers en mémoire créé par le noyau.
  • /run, un emplacement de système de fichiers standardisé pour les démons.
  • /sys. Cela vous permet d'obtenir des informations sur le système et ses composants.

Cela signifie qu'il n'y a plus grand chose à faire et pas grand chose à faire là-bas. Vous ne pouvez pas ls (bien qu'en utilisant Languette, les noms des répertoires et des fichiers sont toujours affichés). Vous pouvez cd dans différents répertoires, et aussi echo des choses, mais des commandes telles que cat ne sont plus disponibles.

Il n'y a pas sudo non plus.

shutdown -h now et reboot a disparu aussi, donc votre seule option semble être d'éteindre la machine manuellement. Connectez - Out (exit) ne fonctionne pas, même s’il affiche un joli texte de "déconnexion".

Une fois que vous essayez de redémarrer la machine, vous vous retrouvez avec une belle erreur GRUB 15, et puis, rien ne se passe, à quel point vous pouvez commencer à penser que votre rm aurait pu faire quelque chose de mal à votre système.

enter image description here

Tu peux le faire aussi

Non, attends, ne le fais pas sur ta machine!

Ce que vous pouvez faire à la place est de lancer un machine virtuelle. Les machines virtuelles ont l'avantage de faciliter l'expérimentation. Comme vous utilisez Ubuntu, vous pourriez être intéressé par vmbuilder. C'est un outil qui vous permet de déployer des machines virtuelles en quelques minutes (la documentation officielle affirme que cela peut être fait "en une minute environ", mais le temps réel, même sur un matériel rapide, est plus de deux à trois minutes). .

Une fois le déploiement terminé, vous disposez d'un environnement avec lequel vous pouvez jouer. Si vous finissez par le détruire, peu importe: vous redéployez la machine et vous pouvez continuer deux minutes plus tard.

Si vous utilisez un logiciel tel que VMWare, vous pouvez également être intéressé par des instantanés (Notez que le lecteur VMWare gratuit n’a pas cette fonctionnalité; vous devez acheter VMware Workstation). Notez que Hyper-V est gratuit et prend en charge les snapshots (mais vous devez exécuter Windows).

L'avantage des instantanés est que vous pouvez en prendre une en quelques millisecondes. Revenir à un instantané prend plus de temps, mais dure souvent quelques secondes. Cela rend l'expérimentation encore plus facile et rapide.

Cette expérimentation n'est pas limitée au système d'exploitation lui-même. Vous pouvez faire toutes sortes de choses impliquant des logiciels. Vous avez une application suspecte? Testez-le sur une machine virtuelle - si c'est un virus, il ne fera aucun mal. Vous souhaitez tester une opération sur une base de données, étant donné que cela peut affecter l'environnement? Testez-le sur une VM.

Et si vous le faisiez sur une vraie machine non testée?

Les mauvaises choses arrivent. Notez que rm vous protège de vous-même: rm -rf / ne marchera pas: vous devez utiliser --no-preserve-root. Pourtant, que se passe-t-il si vous réalisez, par erreur, tout supprimer?

rm ne dissocie que les fichiers, mais les données sont toujours là, sur votre disque dur. Cela permet de le récupérer plus tard (c'est pourquoi vous ne devriez pas simplement jeter vos disques durs avec des données sensibles lorsqu'ils ne fonctionnent plus).

Cela signifie que vous devez juste avoir un PC de rechange avec un boîtier de disque dur pour récupérer pratiquement tout les fichiers. L'important est d'éviter d'écrire quoi que ce soit sur le disque dur pour récupérer: les données que vous écrivez écrasent les fichiers non liés.

Comme noté par l'article dans le commentaire de 200_successSi vous agissez intelligemment, vous pouvez récupérer la machine même sans PC de rechange. Si vous vous souciez uniquement des données, cela ne me dérangerait pas: le récupérer avec un PC de rechange est beaucoup plus facile.


54
2018-04-02 18:06



VirtualBox prend en charge les instantanés de disque. - Nathan Osman
Notez que les virus sont souvent conçus pour détecter les machines virtuelles. Je ne conseillerais donc pas ce processus de détection de virus. Une petite question: ces quatre répertoires restants ne sont pas de "vrais" répertoires, non? Ils ne sont pas réellement sur le disque dur? Que reste-t-il sur le disque dur après avoir exécuté cette commande? - raptortech97
@ raptortech97 rm ne supprime pas vraiment les données du disque dur, il "dissocie" (dissocie) les données réelles du disque à partir de l'arborescence du système de fichiers, en les marquant comme libre (afin qu'elles puissent éventuellement être écrasées par un usage normal de l'ordinateur). Donc, si vous dites rm -rf ~, tout n'est pas perdu, tant que vous agissez rapidement (par exemple avec extundelete). Vous pouvez le considérer comme une version encore moins fiable du dossier "supprimé" de votre boîte aux lettres, vous pouvez récupérer des données si vous n'attendez pas trop longtemps, mais il sera finalement purgé. - Thomas
@ raptortech97 Par contre, si pour une raison quelconque vous n'avez pas utilisé rm mais shred, c'est quasiment fini, bien que vous ayez probablement le temps de réaliser votre erreur et d'annuler car le déchiquetage prend plus de temps. - Thomas
Les répertoires conservés sont très probablement des points de montage d'une forme ou d'une autre. Et les commandes qui continuent à fonctionner sont des commandes intégrées bash, pas des binaires séparés. Donc pendant lsest parti, for i in /*; do echo $i; done devrait marcher. Et pour remplacer cat vous pourriez utiliser une commande comme while read i; do echo $i; done < /proc/self/maps. - MvG


La raison en est que la couche de nommage des fichiers (ce que vous voyez avec ls) est vraiment juste pour votre commodité. Le pilote du système de fichiers et le noyau ne concernent que l’inode. Lorsqu'un fichier est référencé par son nom, il est immédiatement traduit dans l'inode qui contient toutes les métadonnées, y compris les autorisations, les blocs de données sur le disque, l'ID du propriétaire, l'ID du groupe et le nombre de liens.

Le nombre de liens est ce qui compte vraiment ici. Lorsque vous supprimez un fichier sur un système UNIX, l'appel système réel est un unlink. Ce qui se passe sous le capot est que le nombre de liens (le nombre de noms de fichiers dans la couche de dénomination des fichiers) qui pointe vers cet inode est décrémenté. Le système de fichiers sait qu'un fichier est supprimé lorsque le nombre de liens atteint zéro.

Lorsqu'un fichier est supprimé par rm il éditera également le fichier de répertoire (oui, c'est juste un fichier qui contient le nom du fichier et l'inode en plus de quelques autres bits qui ne sont pas importants pour cette réponse). Cependant, c'est la dissociation qui libère réellement les ressources du disque.

Cela conduit à d'autres effets intéressants. Tout d'abord, il est possible d'ouvrir un fichier dont le nombre de liens est égal à zéro. Cela se produit quand rm -rf / supprime l'entrée pour /bin/rm. Le fichier est ouvert (il y a un descripteur de fichier) mais l'inode est marqué comme étant supprimé (nombre de liens = 0). Les ressources du disque ne seront pas libérées et réutilisées tant que le descripteur de fichier ne se ferme pas.

Un autre effet intéressant est ce qui se produit lorsque vous avez un inode avec un nombre de liens supérieur à zéro, mais rien dans la couche de dénomination des fichiers qui pointe vers lui. C'est en quelque sorte un fichier très bien caché :). Pour y accéder, vous devez utiliser un niveau faible pour le référencer par numéro d'inode plutôt que par nom (car il n'y en a pas) ou éditer une entrée de répertoire pour pointer sur l'inode à l'aide d'un éditeur hexadécimal.

Un troisième effet intéressant est ce qui se passe si vous réduisez le nombre de liens à zéro, mais de toute façon, pointez une entrée de répertoire à l’inode. Je vous laisse le soin d'expérimenter si vous le souhaitez. De toute évidence, ces deux derniers éléments font que le système de fichiers est dans un état incohérent.


25
2018-04-02 13:08



En regardant d'une autre manière, le nombre de liens n'est pas nul, car l'ouverture d'un fichier ajoute un lien dans / proc. - OrangeDog
@OrangeDog, ce comportement existe toujours même si procfs est démonté. - Charles Duffy
@OrangeDog Charles Duffy a raison. Le fichier gère dans / proc do ne pas modifier les inodes, en ajustant le nombre de liens. - David Hoelzer
/ proc et / sys sont des reflets de l'état actuel du système (noyau). Seules les actions à sélectionner dans les fichiers et les répertoires modifient l'état du système. - Michael Kjörling


Les réponses précédentes sont bonnes, mais je veux clarifier un détail:

rm n'est pas juste une commande. C'est un programme qui se trouve dans PATH.

Par conséquent, que se passe-t-il lorsque vous exécutez est la suivante:

  • vous appelez (en tant que root) rm -rf /
  • exemple de programme rm est chargé en mémoire avec des arguments -rf et /
  • basé sur ces arguments programme rm commence ses opérations (en parcourant tout ce qui est monté / partition et en supprimant récursivement les références à ce dernier [désolé pour la technicité;)])
  • une fois terminé, l'instance de rm le programme est déchargé
  • à ce stade, les seuls éléments en mémoire sont les programmes qui y ont été chargés précédemment (par exemple, bash si vous avez un terminal ouvert dans Ubuntu, un environnement de bureau, un noyau, des pilotes, etc.)
  • Si vous essayez d'appeler une autre commande (ce qui, dans le cas de Linux, en fait un programme autonome), elle échouera car aucun programme de ce type ne se trouve dans les emplacements PATH (et les emplacements PATH n'existent plus). Cependant tout ce qui a été chargé une fois fonctionnera encore

Juste pour comprendre comment cela fonctionne, installez LAMP sur ubuntu (dans Virtualbox), certains scripts et cache d'opcode PHP, puis appelez cette commande maléfique. Étonnamment (si vous êtes assez chanceux et que votre cache d'opcode ne remarquera pas la suppression du fichier php), vous pouvez toujours accéder aux scripts php depuis l'extérieur via le serveur web apache!

PS: cette commande maléfique a même fonctionné en tant que root ne supprimera pas everything, il ne peut pas supprimer certains processus privilégiés du noyau de /proc et ne peut pas supprimer certaines choses de /dev appareils qui apparaissent sur votre système en tant que fichiers. En fait, root n’est pas aussi puissant que nous le pensons, d’autre part, le noyau est.

PPS: En second lieu, vous penserez également que vous aurez toujours des fichiers locked par un autre processus au moment de la tentative de suppression.


18
2018-04-02 11:45



Sous Linux, vous pouvez certainement supprimer des nœuds de périphérique lors de l'exécution en tant que root. Mais oui, vous ne pouvez rien supprimer de /proc comme c'est un système de fichiers en lecture seule. De même pour /sys. Je crois que vous ne pouvez pas non plus supprimer les points de montage. - Brian
@AlexKey Je suggère de modifier ce que vous entendez par "commande non intégrée au noyau" (ou d'éviter cette phrase). On dirait que vous dites qu'il y a des commandes que vous pouvez exécuter par un shell qui est implémenté directement dans le noyau afin de toujours fonctionner, peu importe quoi. (Ce qui est, comme vous le savez probablement, mais de nombreux lecteurs ne le peuvent pas, pas le cas: lorsque vous exécutez une commande comme cd, cela appelle le shell intégré par ce nom - cette commande est intégrée au shell, pas au noyau.) Voulez-vous dire "commandes" Alt + SysRq? - Eliah Kagan
@Brian dépend-il de la distribution? J'ai travaillé dans une variété de distributions et aussi drôle que cela puisse paraître a fait cette erreur à plusieurs reprises. Comme je le rappelais après avoir inspecté les restes de / il y avait encore quelque chose dans / dev, mais ça pouvait être des choses comme le cdrom ou la disquette ... - Alexey Kamenskiy
@EliahKagan Comme j'ai essayé de rester indépendant de la distribution, j'ai donc utilisé ce terme. Cela signifie que pas sur tous les systèmes de commande cli signifie programme externe. Mais merci, pour le souligner, je vais clarifier le point. - Alexey Kamenskiy
@AlexKey Je crois que vous ne pourriez pas supprimer /dev/pts puisque c'est un point de montage. (Et un système de fichiers en lecture seule également.) - Brian


Une fois que tout est effacé des disques durs, le noyau fonctionne toujours, mais il reste en quelque sorte bloqué car il ne reste plus de périphériques et de programmes, de commandes, etc.

L'OS ne fonctionnera plus.

Et c'est vrai ce que dit Oli, la commande est chargée / exécutée en mémoire et rien ne l'arrêtera si vous ne tuez pas ce processus (bien sûr, si la commande kill est toujours présente ^^).


1
2018-04-02 09:35



Pourquoi le noyau serait-il bloqué? La réponse de MainMa suggère le contraire et soutient ce à quoi je m'attendais. - MvG
Les programmes s'exécutent à partir de la mémoire, pas du disque dur. Le noyau ne saura rien avant un redémarrage. - phyrfox
Eh bien peut-être que je dois changer les mots que j'ai utilisés, le noyau est plus ou moins "bloqué" sans périphériques, programmes, etc. et si vous n'êtes pas devant la console racine, vous ne pouvez pas faire de mauvaises choses, console tu ne peux pas faire de mauvaises choses. Mais je vais changer ma formulation dans ma réponse car elle est trompeuse, je suis d'accord. - s1mmel


Sachez que si le système a selinux et selinux est en mode application, et que les règles de selinux sont correctement configurées; alors rien ne se passera.

Selinux est un contrôle d'accès obligatoire, ce qui signifie, entre autres choses, que l'utilisateur root n'a pas vraiment plus de pouvoir pour détruire le système que tout autre utilisateur du système.

Selinux est appliqué dans le noyau; vous devrez compromettre le noyau pour le contourner.

Sur un système bien conçu avec de bonnes politiques Selinux, root ne pourrait pas faire grand chose sur le système.

Les révisions ultérieures d'Android ont Selinux juste pour cette raison.


0
2018-04-03 02:38