Y a-t-il un scénario où rm -rf -no-preserve-root est nécessaire?

J'ai vu quelques questions ici où les gens font accidentellement rm -rf --no-preserve-rootou rm -rf *effacent la plupart ou la totalité de leur système de fichiers avant de pouvoir réagir.

Y a-t-il jamais une raison d'utiliser --no-preserve-root, que ce soit en utilisation normale, en tant que développeur ou en tant qu'administrateur?

IMPORTANT: les systèmes UEFI modernes montent le micrologiciel sous le /sysrépertoire et le mettent à la disposition du système d'exploitation. N'EXÉCUTEZ PAS cette commande sur un système moderne car cela supprimera ce micrologiciel, essentiellement en brickant votre machine.

Le scénario le plus simple auquel je peux penser est que quelqu'un souhaite supprimer toutes les données de son lecteur. Il peut y avoir des raisons parfaitement légitimes de le faire et la façon la plus simple à laquelle je peux penser est

rm -rf --no-preserve-root /

Il s'avère que celui-ci est en fait donné comme exemple dans info rm:

`--no-preserve-root'
    Do not treat `/' specially when removing recursively.  This option
    is not recommended unless you really want to remove all the files
    on your computer. 

Une autre bonne raison est que vous souhaitez supprimer un système de fichiers monté dans lequel vous avez chrootentré. Dans ce cas, rm -rf --no-preserve-root /supprimera le système dans l' chrootenvironnement mais laissera le vôtre intact.

Je suis sûr qu'il y a plus de raisons possibles, mais en général, il semble très raisonnable que mon système me permette d'en faire ce que je veux. C'est mon travail de faire attention, le système ne doit me permettre que de faire ce que je veux faire. Si ce que je veux est stupide, c'est mon problème et non celui du système d'exploitation.

Quoi qu'il en soit, il s'agit d'une restriction relativement nouvelle, elle a été ajoutée dans la 7e version de la spécification POSIX (la précédente est ici), avant que ce rm -rf /soit une commande parfaitement valide. Sur une note historique, les répertoires .et ..ont toujours été protégés depuis rm, depuis 1979, date à laquelle ils ont rmacquis la possibilité de supprimer des répertoires. Plus à ce sujet ici .

L'existence du --no-preserve-rootcommutateur n'est pas pour ajouter des fonctionnalités supplémentaires mais pour remplacer une réduction très saine des fonctionnalités. Ce commutateur est probablement basé sur la philosophie selon laquelle l'ordinateur doit faire ce qui lui est demandé et que des commandes doivent être disponibles pour exprimer toute action souhaitée. Ce commutateur est antérieur à l'UEFI, et d'après mon expérience, je dis qu'il est désormais obsolète.

Dans la pratique moderne, sans ce commutateur, la rmcommande évite la suppression accidentelle du répertoire racine lors de l'utilisation d'une variable non initialisée ou d'un espace parasite.

rm -rf /${my_directory}
rm -rf / var/log/httpd/*

Note de bas de page amusante: la protection n'était pas son intention. Selon un blog de Sun Microsystems, la suppression du /répertoire supprimera implicitement le répertoire de travail actuel, une violation de la considération spéciale déjà faite pour les répertoires .et ... C'est pourquoi leur comité des normes a autorisé cette exception spéciale - pas pour prévenir un accident. Cette modification a été introduite pour la première fois avec Solaris 10 build 36.

http://archive.is/5lmc9

Ce n'est peut-être pas une réponse que le demandeur d'origine veut, mais il existe un cas d'utilisation qui doit supprimer tous les fichiers de manière récursive du répertoire racine. Bien que cela ne passe pas par la rmcommande, cela fait partie du processus switch_root (8) lors du démarrage de votre système Linux (non intégré).