Pourquoi chmod -R 777 / destructif ?

Solution 1 :

Tout d'abord une petite précision terminologique :chmod ne supprime pas autorisations. Il CHANGE leur.

Maintenant le coeur du problème -- Le mode 777 signifie "N'importe qui peut lire, écrire ou exécuter ce fichier" - Vous avez accordé la permission pour que n'importe qui fasse (efficacement) tout ce qu'il veut.

Maintenant, pourquoi est-ce mauvais ?

Vous venez de laisser tout le monde lire/modifier chaque fichier de votre système.
- Dites adieu à la sécurité des mots de passe (n'importe qui peut lire le fichier fantôme et déchiffrer vos mots de passe, mais pourquoi s'embêter ? CHANGEZ simplement le mot de passe ! C'est beaucoup plus facile !).
- Dites adieu à la sécurité de vos fichiers binaires (quelqu'un peut simplement écrire un nouveau login programme qui les laisse entrer à chaque fois).
- Dites adieu à vos fichiers :un utilisateur détourne rm -r / et tout est fini. On a dit au système d'exploitation de les laisser faire ce qu'ils voulaient !
Vous avez énervé tous les programmes qui vérifient les autorisations sur les fichiers avant de commencer.
sudo , sendmail , et une foule d'autres ne démarreront tout simplement plus. Ils examineront les autorisations des fichiers clés, verront qu'ils ne sont pas ce qu'ils sont censés être et renverront un message d'erreur.
De même ssh se cassera horriblement (les fichiers clés doivent avoir des autorisations spécifiques, sinon ils ne sont pas "sécurisés" et par défaut SSH refusera de les utiliser.)
Vous avez effacé les bits setuid / setgid sur les programmes qui les avaient.
Le mode 777 est en fait 0 777 . Parmi les éléments de ce premier chiffre se trouvent le setuid et setgid morceaux.
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.
Vous avez cassé /tmp et /var/tmp L'autre chose dans ce premier chiffre octal qui a obtenu zéro est le sticky bit -- Celui qui protège les fichiers en /tmp (et /var/tmp ) d'être supprimé par des personnes qui ne les possèdent pas.
Il y a (malheureusement) beaucoup de scripts qui se comportent mal qui "nettoient" en faisant un rm -r /tmp/* , et sans le sticky bit défini sur /tmp vous pouvez dire adieu à tous les fichiers de ce répertoire.
Faire disparaître des fichiers de travail peut vraiment perturber certains programmes mal écrits...
Vous avez causé des ravages en /dev /proc et systèmes de fichiers similaires
C'est plus un problème sur les anciens systèmes Unix où /dev est un vrai système de fichiers, et les éléments qu'il contient sont des fichiers spéciaux créés avec mknod , car la modification des autorisations sera préservée lors des redémarrages, mais sur tout système dont les autorisations de votre appareil changent, cela peut entraîner des problèmes importants, des risques de sécurité évidents (tout le monde peut lire chaque TTY) aux causes potentielles moins évidentes d'une panique du noyau.
Credit to @Tonny for pointing out this possibility
Les prises et les tuyaux peuvent se casser ou présenter d'autres problèmes Les sockets et les tuyaux peuvent se casser complètement ou être exposés à une injection malveillante en raison de leur accessibilité en écriture.
Credit to @Tonny for pointing out this possibility
Vous avez rendu chaque fichier de votre système exécutable
Beaucoup de gens ont . dans leur PATH variable d'environnement (vous ne devriez pas !) - Cela pourrait causer une mauvaise surprise car maintenant n'importe qui peut déposer un fichier nommé de manière pratique comme une commande (disons make ou ls , et essayez de vous faire exécuter leur code malveillant.
Credit to @RichHomolka for pointing out this possibility
Sur certains systèmes chmod réinitialisera les listes de contrôle d'accès (ACL)
Cela signifie que vous devrez peut-être recréer toutes vos ACL en plus de corriger les autorisations partout (et c'est un exemple réel de la commande destructrice).
Credit to @JamesYoungman for pointing out this possibility

Les parties du système qui fonctionnent déjà continueront-elles à fonctionner ? Probablement, pendant un certain temps au moins.
Mais la prochaine fois que vous aurez besoin de lancer un programme, ou de redémarrer un service, ou que Dieu vous en préserve, REDÉMARREZ la boîte dans laquelle vous vous trouvez pour un monde de souffrance, car les n° 2 et n° 3 ci-dessus lèveront la tête.

Solution 2 :

Une chose importante 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 erronées, 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 possibilité de se connecter échoue, probablement parce que le binaire de connexion ou quelque chose dans PAM a des vérifications d'autorisation.

Ce n'est donc pas vraiment que le système est détruit, c'est que 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 avoir fait un chmod 777 -R / il démarrera et vous pourrez démarrer des processus qui n'ont pas de contrôles d'autorisation explicites. Le système n'est donc pas vraiment mort, juste quelque peu inutilisable de par sa conception .