Pourquoi “chmod -R 777 /” est-il destructif?

C’est une question canonique sur l’autorisation de fichier et pourquoi 777 est "destructif".

Je ne vous demande pas comment résoudre ce problème, car il existe déjà une tonne de références sur Server Fault (réinstallez le système d'exploitation). Pourquoi fait-il quelque chose de destructeur?

Si vous avez déjà exécuté cette commande, vous détruisez presque immédiatement votre système d'exploitation. Je ne comprends pas pourquoi la suppression des restrictions a un impact sur les processus existants. Par exemple, si je n'ai pas accès en lecture à quelque chose et après un brouillage rapide dans le terminal, tout à coup, j'ai maintenant bien accès ... pourquoi cela cause-t-il une panne de Linux?

Tout d'abord, un nitpick de terminologie mineure: chmodne supprime pas les autorisations. Cela les change .

Maintenant le fond du problème - Le mode 777signifie "Tout le monde peut lire, écrire ou exécuter ce fichier" - Vous avez donné la permission à quiconque de faire (efficacement) ce qu'il veut.

Maintenant, pourquoi est-ce mauvais?

1. Vous venez de laisser tout le monde lire / modifier tous les fichiers de votre système.
   • Fini la sécurité des mots de passe (tout le monde peut lire le fichier shadow et déchiffrer vos mots de passe, mais pourquoi s'en préoccuper? Il suffit de CHANGER le mot de passe! C'est beaucoup plus simple!).
   • Au revoir sécurité pour vos fichiers binaires (quelqu'un peut simplement écrire un nouveau loginprogramme qui les laisse entrer à tout moment).
   • Dites adieu à vos fichiers: un utilisateur vous dirige mal rm -r /et tout est fini. On a dit à l'OS de les laisser faire ce qu'ils voulaient!
2. Vous avez pissé tous les programmes qui vérifient les autorisations sur les fichiers avant de commencer.
   sudo, sendmailet une foule d’autres ne commenceront tout simplement plus. Ils examineront les droits d'accès aux fichiers clés, constateront qu'ils ne sont pas ce qu'ils sont censés être et renverront un message d'erreur.
   De la même manière ssh, les disques casseront horriblement (les fichiers de clé doivent avoir des autorisations spécifiques, sinon ils sont "non sécurisés" et par défaut, SSH refusera de les utiliser.)
3. Vous avez effacé les bits setuid / setgid sur les programmes qui les avaient.
   Le mode 777est réellement . Parmi les éléments de ce premier chiffre figurent les bits et . La plupart des programmes qui sont setuid / setgid ont ce bit défini car ils doivent s'exécuter avec certains privilèges. Ils sont cassés maintenant.0777setuidsetgid
   
4. Vous avez cassé /tmpet/var/tmp L'autre élément de ce chiffre octal qui a été mis à zéro est le sticky bit- Cela protège les fichiers entre /tmp(et /var/tmp) d'être supprimés par des personnes qui ne les possèdent pas.
   Il y a (malheureusement) beaucoup de scripts mal conçus qui "nettoient" en faisant un rm -r /tmp/*, et sans le truc collant, /tmp vous pouvez embrasser tous les fichiers de ce répertoire.
   Faire disparaître des fichiers de travail peut vraiment perturber certains programmes mal écrits ...
5. Vous avez causé des dégâts dans /dev /procdes systèmes de fichiers similaires.
   Il s'agit davantage d'un problème sur les systèmes Unix plus anciens, qui /devsont un système de fichiers réel, et les éléments qu'il contient sont des fichiers spéciaux créés avec mknod, car les modifications apportées aux autorisations seront préservées lors des redémarrages, mais sur tout système. le fait de modifier les autorisations de votre appareil peut entraîner des problèmes importants, allant des risques de sécurité évidents (tout le monde peut lire chaque ATS) aux causes moins évidentes d'une panique du noyau.
   Credit to @Tonny for pointing out this possibility
6. Les sockets et les pipes peuvent se briser ou avoir d'autres problèmes Les sockets et les pipes peuvent se briser entièrement ou être exposés à une injection malveillante du fait de leur possibilité d'écriture.
   Credit to @Tonny for pointing out this possibility
7. Vous avez créé chaque fichier sur votre exécutable système
   De nombreuses personnes ont .dans leur PATHenvironnement une variable (vous ne devriez pas!) - Cela pourrait causer une mauvaise surprise car tout le monde peut maintenant déposer un fichier nommé commodément comme une commande (par exemple, makeou ls, et avoir une chance de vous faire exécuter leur code malveillant.
   Credit to @RichHomolka for pointing out this possibility
8. Sur certains systèmes chmod, les listes de contrôle d'accès (ACL) seront réinitialisées.
   Cela signifie que vous devrez peut-être recréer toutes vos listes de contrôle d'accès en plus de fixer les autorisations partout (ce qui constitue un exemple réel de destruction de la commande).
   Credit to @JamesYoungman for pointing out this possibility

Les parties du système en cours d'exécution continueront-elles à fonctionner? Probablement pendant au moins un moment.
Mais la prochaine fois que vous aurez besoin de lancer un programme, de redémarrer un service, ou encore, interdisez de redémarrer la boîte dans laquelle vous vous trouvez pour un monde blessé, car les n ° 2 et n ° 3 ci-dessus se dresseront la tête laide.

Un aspect important est qu’il existe de nombreux outils comme ssh / sudo qui vérifient les autorisations du système de fichiers pour les fichiers de configuration clés. Si les autorisations sont incorrectes, ces outils sont conçus pour échouer, car cela indiquerait un grave problème de sécurité. Sur mon système de test Debian et peut-être sur d'autres, la capacité de connexion échoue, probablement parce que le binaire de connexion ou quelque chose dans PAM dispose de contrôles d'autorisation.

Ce n'est donc pas vraiment que le système est détruit, mais bien de nombreux outils sont conçus pour échouer immédiatement lorsque les autorisations sont erronées.

Si vous redémarrez un système après l'avoir effectué, chmod 777 -R /il démarrera, et vous pouvez démarrer des processus sans vérification explicite des autorisations. Ainsi, le système n'est pas vraiment mort, mais une conception un peu inutilisable .