Pourquoi chmod 777 -R / laisse-t-il le système inutilisable?

52

J'accorde seulement la permission à tous de faire quoi que ce soit, mais pourquoi le système se bloque-t-il en donnant des autorisations uniquement? Je ne fais que modifier l'autorisation sans changer les fichiers.

chmod

— Brij Raj Kishore
source

12

Related: serverfault.com/questions/364677/why-is-chmod-r-777-destructive

— Glen

2

Je pense que cela ne plante pas, mais plutôt que d’annuler le processus de démarrage à un moment donné. Si vous regardiez /var/log/syslog, vous découvririez même la raison.

— Bonjour Angel

7

Il est important de savoir que même si cela ne cassait pas les choses, cela ne " donnerait pas la permission à tous de faire quoi que ce soit". Il y aurait toujours un grand nombre d'actions que seule la "racine" (plus précisément, un processus avec un UID nul effectif) pourrait faire.

— dimanche

6

@Glen si par "lié", vous voulez dire "une copie exacte qui montre pourquoi nous devrions être en mesure de marquer comme dupe sur plusieurs sites", alors bien sûr! excellent lien. ;)

— underscore_d

4

J'adorerais vraiment entendre l'histoire de vous poser cette question.

— Dewi Morgan

104

Il y a plusieurs raisons.

En plus des autorisations habituelles lecture / écriture / exécution, il existe d’autres bits que les autorisations de fichiers contiennent. Plus particulièrement setuidet setgid. Lorsqu'un programme est défini avec l'un de ces bits d'autorisation, il obtient "l'UID effectif" et / ou le "GID effectif" du propriétaire du programme plutôt que de l'utilisateur qui l'a exécuté. Cela permet aux programmes de s'exécuter avec plus d'autorisations que l'utilisateur qui les a exécutés. Il est utilisé par de nombreux utilitaires système essentiels, notamment suet sudo. Votre chmodcommande efface ces bits, laissant les utilitaires inutilisables.

Deuxièmement, certains programmes (notamment ssh) vérifient l'intégrité des autorisations de fichiers et refusent d'utiliser des fichiers avec des autorisations qu'ils considèrent comme non sécurisées. Cela réduit le risque que des administrateurs insouciants laissent accidentellement des failles de sécurité, mais rend encore plus pénible la gestion des autorisations de fichiers effacées.

— Peter Green
source

41

Une réponse courte.

Le système Linux nécessite des autorisations spécifiques pour certains programmes tels que sudo, etc.

Lorsque vous exécutez, chmod 777 -R /supprimez toutes les autorisations et remplacez-les par 777. Cela rend le système inutilisable à moins que vous ne restauriez manuellement toutes les autorisations.

En pratique, il est beaucoup plus rapide et facile à réinstaller.

Le problème est que de nombreux programmes système sont conçus de manière à ne pas démarrer s'ils "n'aiment pas" les autorisations. Ceci est fait pour des raisons de sécurité.

Je pense qu'il est plus important d'expliquer comment gérer la conception du système en parallèle que d'expliquer pourquoi chaque programme ne fonctionne pas avec de mauvaises permissons.

Si vous voulez vraiment que tous les utilisateurs aient des autorisations illimitées dans Ubuntu, vous pouvez ajouter tous les utilisateurs au sudogroupe au lieu de modifier les autorisations de fichiers et de répertoires. Cela aura le même effet, mais ne ruinera pas le système.

Une autre façon (très mauvaise) consiste à activer le compte root et à permettre à tout le monde de se connecter en tant que root.

— Pilote6
source

11

Peut-être que quelqu'un va prendre le temps de faire une réponse détaillée ;-)

— Pilot6

1

Je pourrais indiquer un meilleur moyen de permettre à tout le monde de tout faire sur ce système - mais écrire un article détaillé expliquant pourquoi chaque binaire a besoin de ses autorisations, paramètres et indicateurs spécifiques est un peu trop, à mon humble avis. ;-)

— Phillip -Zyan K Lee- Stockmann

4

Les systèmes Linux ne sont pas conçus pour permettre à tout le monde de tout faire. Vous pouvez activer le compte root et tout le monde peut se connecter en tant que root pour cela. C'est stupide, mais c'est comme ça.

— Pilot6

9

Donc, Pilote6, vous voulez dire que les programmes système ont été conçus de manière à ce que si les autorisations sont mauvaises, ils ne sont pas autorisés / ne peuvent pas fonctionner correctement? Et s'il vous plaît Pilote6 si possible s'il vous plaît fournir une réponse plus profonde avec des exemples et une explication pourquoi certaines applications nécessitent des autorisations limitées. Merci.

— Brij Raj Kishore

13

@Goldname Le crash est l'erreur - il y a un grand nombre de programmes disant "Je ne peux pas exécuter de fonctions critiques avec le système dans cet état, donc

— j'abandonne

32

chmod a des nuances subtiles.

chmod 0777se comporte différemment chmod u+rwx,g+rwx,o+rwxen ce sens que setuid et setgid sont mis à zéro par le premier et conservés par ce dernier.

C'est pourquoi le système est devenu inutilisable. Vous avez supprimé le setuid nécessaire de quelques programmes.

Voici une liste des fichiers setuid ou setgid sur mon ordinateur portable Linux Fedora 23:

[root@fedora23lnvr61]# find / -perm /g+s,u+s
/var/log/journal
/var/log/journal/75e870eb13c74fbf97556a32ecf80ea2
/opt/google/chrome/chrome-sandbox
/usr/bin/rogue
/usr/bin/gnuchess
/usr/bin/locate
/usr/bin/umount
/usr/bin/lbrickbuster2
/usr/bin/gpasswd
/usr/bin/crontab
/usr/bin/fusermount
/usr/bin/su
/usr/bin/at
/usr/bin/newuidmap
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/mount
/usr/bin/chsh
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/chage
/usr/bin/chfn
/usr/bin/write
/usr/bin/newgidmap
/usr/sbin/mount.nfs
/usr/sbin/lockdev
/usr/sbin/netreport
/usr/sbin/userhelper
/usr/sbin/usernetctl
/usr/sbin/unix_chkpwd
/usr/sbin/pam_timestamp_check
/usr/libexec/kde4/kdesud
/usr/libexec/kde4/kpac_dhcp_helper
/usr/libexec/dbus-1/dbus-daemon-launch-helper
/usr/libexec/qemu-bridge-helper
/usr/libexec/openssh/ssh-keysign
/usr/libexec/spice-gtk-x86_64/spice-client-glib-usb-acl-helper
/usr/libexec/utempter/utempter
/usr/libexec/abrt-action-install-debuginfo-to-abrt-cache
/usr/libexec/Xorg.wrap
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/lib64/vte-2.90/gnome-pty-helper
/usr/lib64/virtualbox/VBoxSDL
/usr/lib64/virtualbox/VirtualBox
/usr/lib64/virtualbox/VBoxNetNAT
/usr/lib64/virtualbox/VBoxHeadless
/usr/lib64/virtualbox/VBoxNetDHCP
/usr/lib64/virtualbox/VBoxNetAdpCtl
/usr/lib64/virtualbox/VBoxVolInfo
/usr/lib64/vte/gnome-pty-helper
[root@fedora23lnvr61]#

J'ai supprimé des dizaines d'entrées de bruit dans les caches et les journaux.

— Wallyk
source

3

Puis-je me demander pourquoi la gnuchesse et le voyou sont sur cette liste?

— WiseOldDuck

2

@WiseOldDuck: Je m'attends à ce que les jeux aient le bit nécessaire pour pouvoir mettre à jour leur fichier "score élevé" mais ne permettent à aucun utilisateur non privilégié de le faire.

— Wallyk

3

@WiseOldDuck Comme le dit wallyk, en outre, rappelez-vous que setuid n'a pas nécessairement besoin d'utiliser de racine (et afaik setgid n'est pas vraiment utile pour root)

— StarWeaver

5

Je suis prêt à prendre la peine d'expliquer ce qui chmodse passe et de fournir des exemples de preuves, ce qui fait très défaut ailleurs.

— underscore_d

1

Est-ce que cela signifie que chmod u+rwx,g+rwx,o+rwx -R /cela ne cassera pas le système?

— Dennis Jaheruddin

15

En plus des autres réponses: vous avez également supprimé le "sticky bit" /tmp(qui possède généralement les autorisations 1777), ce qui pourrait entraîner d'autres problèmes inattendus, car les programmes pourraient écrire ou supprimer les fichiers temporaires des autres utilisateurs.

Le sticky bit est une autorisation spéciale qui, tout en permettant à quiconque de créer des fichiers /tmp, n'autorise que la personne qui l'a créé à le déplacer ou le supprimer.

— Ben XO
source

4

"et cela aurait empêché toute personne autre que la racine d’utiliser le répertoire system / tmp." - Cela ne semble pas juste. Cela permettrait toujours à quiconque d'utiliser le répertoire system / tmp. Aucun bit collant n'est nécessaire si l'utilisateur, le groupe et d'autres disposent de tous les droits. Cela permettrait toutefois à quiconque de supprimer les fichiers d'autres personnes.

— hvd

1

donc Ben si je lance chmod 1777 -R / alors il ne devrait pas y avoir de problème car je ne suis pas en train de vider le bit collant? -

— Brij Raj Kishore

Merci @hvd - vous avez raison et j'ai légèrement modifié le post pour refléter cela.

— Ben XO

@BrijRajKishore, la question reste de savoir pourquoi vous le faites en premier lieu. Ubuntu et les programmes qui le composent ne sont pas conçus pour être exécutés "sans autorisation", pour de nombreuses raisons. Il serait plus judicieux de "su" à la racine.

— Ben XO

1

On ignore si cela entraînera un crash. Il est tout à fait possible que cela se produise, car les applications pourront soudainement se charger des fichiers temporaires des uns des autres, peut-être accidentellement, ce qui pourrait provoquer un blocage. Comme Ubuntu n’est jamais mis à l’essai de cette manière, vous serez probablement le premier à le découvrir. :-) D'autre part, définir le blocage sur chaque dossier du système peut entraîner de nombreux autres problèmes, avec des applications qui s'attendaient à pouvoir manipuler des programmes en raison des autorisations de groupe sur les dossiers (dossiers dotés de permissions 2777).

— Ben XO