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

Peu importe que /bin/rm soit 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.

Encadré / Mise à jour: Par réponse de David Hoelzer (et mentionnée dans les commentaires), l'inode que le lien actif /bin/rm indiquait resterait jusqu'à ce que rm soit terminé (parce que Linux reste 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 les données du disque rm , cela n'affecterait pas ou n'empêcherait pas la fin de la suppression (en supposant que le disque ne soit pas autrement indisponible).

Aucune idée de ce qu’est un inode ou un hardlink? C’est la réponse à cette question.

Quoi qu’il en soit, vous pouvez également supprimer le package du noyau current sans impliquer l’ordinateur. Tant que vous installez une version différente, il sera possible de démarrer.

Encore une fois, cela fonctionne car rm est appelé une seule fois. Les éléments suivants échoueraient après la mort de /bin/rm car ils l'appellent une fois pour chaque nom de fichier:

find / -exec rm {} \;

Cela dit, find / -exec rm -rf {} + et find / -print0 | xargs -0 rm -rf seraient également susceptibles d'échouer car 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 certain stade du processus, /bin/rm pouvait expirer ( et être libérés) avant que le reste des fichiers ne soit supprimé. Ce n'est pas garanti si. Si /bin/ était le dernier répertoire entré, ces méthodes pourraient fonctionner.

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 modifie également le fichier de répertoire (oui, il ne s'agit que d'un fichier contenant le nom du fichier et l'inode en plus de quelques autres bits non importants pour cette réponse). Cependant, c'est la dissociation qui libère 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 lorsque 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 ni libérées ni réutilisées tant que le descripteur de fichier ne se sera pas fermé.

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 un) ou éditer une entrée de répertoire pour pointer vers 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 vais vous laisser 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.

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

rm n'est pas simplement 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 /
• instance du programme rm est chargée en mémoire avec les arguments -rf et /
• sur la base de ces arguments, le programme rm lance ses opérations (en parcourant tout ce qui est monté / partition et en supprimant de manière récursive les références [désolé pour la technicité;)])
• une fois terminé, l'instance du programme rm est déchargée
• À ce stade, les seuls éléments en mémoire sont les programmes chargés précédemment (par exemple, bash si vous avez un terminal ouvert sous Ubuntu, environnement de bureau, noyau, 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 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 malfaisante exécutée en tant que root ne supprimera pas everything , elle ne peut pas supprimer certains processus privilégiés par le noyau de /proc et ne peut pas supprimer certains éléments des périphériques /dev apparaissant sur votre système. 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.

Une fois que tout est effacé des disques durs, le noyau continue de fonctionner, mais il reste bloqué car il ne reste plus d’appareils 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 ^^).

Sachez que si le système a selinux et selinux est en mode application, et que les stratégies 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 beaucoup 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 règles Selinux, root ne pourrait pas faire grand chose sur le système.

Les versions ultérieures d’Android ont Selinux juste pour cette raison.