Pourquoi le terrible 'rm -rf /' est-il même autorisé ?

Pourquoi n'y a-t-il pas une telle protection dans la commande rm ?

Il existe déjà trois garanties :

• Le -r commutateur, sans lequel un répertoire ne peut pas être supprimé.
• Le -i switch, qui vérifie que vous voulez réellement supprimer ce que vous avez demandé de supprimer. Aliasing rm à rm -i active cette protection sauf si vous ajoutez le -f interrupteur pour l'éteindre.
• Propriété du fichier, qui empêche tous les utilisateurs sauf root de supprimer le répertoire racine.

L'ensemble d'outils Unix est comme une tronçonneuse :il a été conçu pour faire des choses très puissantes et être utilisé par des gens qui comprennent ce qu'ils font. Ceux qui marchent négligemment risquent de se blesser. Cela ne veut pas dire que les expérimentés ne font pas d'erreurs, et évidemment Sun et d'autres pensent que les utilisateurs avec root ont besoin d'être protégés d'eux-mêmes.

Cependant, ce cas précis ne devrait-il pas faire exception à cette règle ?

Les gens ont demandé pourquoi nous ne pouvions pas mettre un protège-lame sur le rm tronçonneuse depuis au moins les années 1980. (Probablement plus longtemps, mais mon histoire avec Unix ne remonte pas plus loin que ça.) Vous devez vous poser plus de questions :

• Puisque nous ajoutons des exceptions, quoi d'autre devrait être considéré comme sacré ? Devrions-nous empêcher la suppression récursive de quoi que ce soit dans le répertoire racine pour éviter des erreurs tout aussi dévastatrices comme rm -rf /* ? Qu'en est-il du répertoire personnel de l'utilisateur ? Qu'en est-il de /lib ou /bin ? Devrions-nous avoir une version spéciale de rm pour éviter ces erreurs sur les systèmes avec une disposition de système de fichiers non traditionnelle ?

• Où plaçons-nous l'application de ces interdictions? Juste en rm ou donnons-nous ce travail au noyau ? Depuis rm ne supprime rien (il fait beaucoup d'appels au unlink(2) et rmdir(2) basé sur les arguments), il n'y aurait aucun moyen pour le noyau de détecter que rm visait vraiment / jusqu'à ce que le moment soit venu de le supprimer. Depuis le seul appel au rmdir(2) qui réussirait jamais, c'est quand le répertoire cible est vide, atteignant ce point avec / signifierait que le système est déjà fichu.

Cela dépend de la diffusion. L'ancien Linux sur lequel je suis en ce moment le permet (je pense que je ne l'ai pas testé cependant :-) ) et déclare en man rm :

   --no-preserve-root do not treat '/' specially (the default)

   --preserve-root
          fail to operate recursively on '/'

Sur de nombreuses distributions récentes, vous devez explicitement ajouter --no-preserve-root pour désactiver la sauvegarde. Sinon, l'exécution échouera.

Concernant Ubuntu, voir ce problème où ce comportement est discuté.

L'historique de cette protection selon Wikipedia :

Sun Microsystems a présenté rm -rf / protection dans Solaris 10, publié pour la première fois en 2005. Lors de l'exécution de la commande, le système signale maintenant que la suppression de / n'est pas autorisé. Peu de temps après, la même fonctionnalité a été introduite dans la version FreeBSD de rm utilitaire. GNU rm refuse d'exécuter rm -rf / si le --preserve-root est donnée, ce qui est la valeur par défaut depuis la sortie de la version 6.4 de GNU Core Utilities en 2006.