chmod 755 et 644 : lire et calculer les droits en octal

Un mode octal s’additionne avec 4, 2 et 1
chmod 755 donne tous les droits au propriétaire et la lecture avec l’exécution au groupe et aux autres ; chmod 644 ne laisse l’écriture qu’au propriétaire et la lecture à tout le monde. Chaque chiffre d’un mode octal est la somme de trois bits : 4 pour la lecture, 2 pour l’écriture et 1 pour l’exécution. La page de manuel chmod(1) livrée avec coreutils 9.1 dans Debian bookworm décrit cette addition et rappelle que les chiffres absents comptent comme des zéros de tête. Un 7 réunit les trois droits, un 5 garde la lecture et l’exécution, un 4 ne garde que la lecture. La place du chiffre désigne le public concerné : premier rang pour le propriétaire, deuxième pour le groupe, troisième pour les autres utilisateurs. Cette écriture courte apparaît dans les commandes Linux qui acceptent un mode, comme mkdir -m.
Sommaire
| Chiffre octal | Binaire | Écriture symbolique | Effet sur un fichier | Effet sur un répertoire |
|---|---|---|---|---|
| 0 | 000 | — | aucun accès | aucun accès |
| 1 | 001 | –x | exécution seule, contenu illisible | entrée possible si le nom est connu |
| 2 | 010 | -w- | écriture sans lecture | écriture sans effet sans l’exécution |
| 3 | 011 | -wx | écriture et exécution sans lecture | création et renommage, sans listage |
| 4 | 100 | r– | lecture seule | listage des noms, sans accès aux fichiers |
| 5 | 101 | r-x | lecture et exécution | listage et traversée |
| 6 | 110 | rw- | lecture et écriture | listage seul, écriture sans effet |
| 7 | 111 | rwx | lecture, écriture et exécution | listage, création et suppression |
Le manuel GNU coreutils 9.12 rappelle que la base est toujours l’octal : le mode 55 et le mode 0055 désignent le même jeu de droits, et un mode à cinq chiffres, comme 00755, demande l’effacement des bits setuid et setgid d’un répertoire.
755 et 644 visent trois publics, un chiffre chacun
chmod 755 et chmod 644 se lisent selon le même principe, mais le bit x ne joue pas le même rôle sur un fichier et sur un répertoire. Sur un fichier, 7 autorise la lecture, l’écriture et l’exécution, 6 retient la lecture et l’écriture, 4 la lecture seule. Pour un répertoire, x couvre la traversée : chmod(2) définit x comme le droit de chercher, celui qui ouvre les entrées dont le nom est connu. Le wiki Archlinux en tire deux conséquences pratiques : un répertoire sans x ne s’ouvre pas avec cd, et son bit w reste sans effet tant que x manque. Un dossier en 644 refuse donc l’entrée à tout le monde. La valeur 755 est la plus répandue pour un répertoire et 644 pour un fichier, comme l’écrit le wiki Archlinux. Le mode en clair se lit avec stat -c %a fichier ; ls -l l’affiche en notation symbolique.
| Objet | Mode octal | Écriture symbolique | Affichage de ls -l | Usage courant |
|---|---|---|---|---|
| fichier | 600 | u=rw,go= | -rw——- | fichier qui ne sort pas du compte |
| fichier | 644 | u=rw,go=r | -rw-r–r– | fichier que tout le monde peut lire |
| fichier | 664 | ug=rw,o=r | -rw-rw-r– | fichier de travail en groupe |
| fichier | 755 | u=rwx,go=rx | -rwxr-xr-x | script exécutable par tous |
| répertoire | 700 | u=rwx,go= | drwx—— | dossier privé |
| répertoire | 755 | u=rwx,go=rx | drwxr-xr-x | dossier consultable par tous |
Un répertoire ne se protège pas comme un fichier, et la distinction entre fichiers et répertoires décide du chiffre à écrire. La commande chmod 755 script.sh rend un script exécutable, geste qui clôt l’écriture d’un script shell.
Quand le « qui » manque, l’umask filtre les bits ajoutés
Un mode symbolique écrit sans u, g ni o ne s’applique pas à tout le monde : la page de manuel chmod(1) précise que l’effet est celui de a, sauf pour les bits déjà présents dans l’umask. Le manuel GNU coreutils donne l’exemple d’un umask à 2, qui retire l’écriture aux utilisateurs extérieurs au groupe : +w ajoute alors l’écriture au propriétaire et aux membres du groupe, jamais aux autres. La même commande écrite a+w ignore l’umask et accorde l’écriture à tous. Le manuel présente cette omission comme un garde-fou, celui qui évite d’accorder plus de droits que prévu, et une même commande donne donc deux résultats selon la session ou selon la machine. Un mode octal ne consulte pas l’umask : il pose les trois rangs en absolu pour les trois publics, comme le précise le même manuel.
| Critère | Mode octal | Mode symbolique |
|---|---|---|
| Publics touchés | les trois rangs à la fois | ceux nommés avant l’opérateur |
| État précédent | ignoré, le mode est posé en absolu | utilisé par + et – |
| Bits de l’umask | sans effet | protégés quand le « qui » manque |
| Bits setuid et setgid d’un répertoire | conservés, sauf mode à cinq chiffres | conservés, sauf a-s ou opérateur = |
| Exemple équivalent | 664 | ug=rw,o=r |
Pour viser tout le monde sans dépendre du masque, écrivez le public : a+w, go+w ou un mode octal. La valeur du masque se règle avec la commande umask, et le manuel GNU coreutils rappelle que sa valeur par défaut varie d’un système à l’autre.
Le quatrième chiffre règle setuid, setgid et sticky
Un mode à quatre chiffres place devant les trois rangs un bit spécial : 4 pour setuid, 2 pour setgid et 1 pour le sticky, que la page de manuel chmod(2) écrit 04000, 02000 et 01000. Le sticky empêche la suppression du fichier d’autrui dans un répertoire partagé, et chmod(1) le donne comme le bit des répertoires ouverts à tous, comme /tmp. Un chmod 755 sur un répertoire ne touche pourtant pas aux bits setuid et setgid déjà posés : chmod(1) précise qu’ils sont conservés sauf mention explicite, et qu’il faut écrire 00755, -6000 ou =755 pour les retirer. Ces bits sortent du cadre des trois rangs et relèvent des permissions des utilisateurs et des groupes. Le noyau retire de lui-même le setgid d’un fichier ordinaire quand le groupe du fichier ne correspond à aucun groupe de l’utilisateur, comme l’écrit chmod(2).
Dans la sortie de ls -l, setuid et setgid s’affichent en s quand le bit x est posé, en S sinon, et le sticky en t ou T selon le wiki Archlinux. Répondre à un refus d’accès par chmod 777 ouvre l’écriture à tout le monde ; sur un répertoire sans sticky, chacun peut alors renommer ou supprimer les fichiers des autres.
Les refus de chmod nomment l’opération et le fichier
chmod écrit une ligne par refus, avec le nom du programme, l’opération tentée, le fichier concerné et la raison. Le fichier src/chmod.c du projet coreutils contient ces chaînes, affichées ainsi dans la locale C : changing permissions of, cannot access et invalid mode. Les locales françaises les traduisent, par exemple modification des droits de pour un changement refusé. Un mode refusé par le noyau produit Operation not permitted quand la session n’est pas propriétaire du fichier et ne dispose pas de la capacité CAP_FOWNER, comme l’écrit la page de manuel chmod(2). La raison arrive en dernier, après le nom du fichier, et c’est elle qui indique le remède. Deux de ces refus viennent de la ligne de commande, les deux autres du noyau, et chmod sort avec le code 1 dans les quatre cas.
chmod 755
chmod: missing operand after '755'
Try 'chmod --help' for more information.
chmod 8 rapport.txt
chmod: invalid mode: '8'
Try 'chmod --help' for more information.
chmod 640 rapport-service.txt
chmod: changing permissions of 'rapport-service.txt': Operation not permitted
chmod 644 compte-rendu.txt
chmod: cannot access 'compte-rendu.txt': No such file or directory
Rien à modifier pour un mode sans nom de fichier : la commande a reçu 755 mais aucune cible. Ajouter le nom suffit, comme dans chmod 755 rapport.txt.
Le chiffre 8 n’existe pas en octal, qui s’arrête à 7. Pour un fichier que seul son propriétaire doit lire et modifier, la valeur juste est 600.
Operation not permitted : le fichier appartient à un autre compte, et seul son propriétaire ou un processus privilégié peut en changer les droits. ls -l donne le nom du propriétaire avant de relancer la commande avec sudo.
No such file or directory : le chemin indiqué n’existe pas depuis le répertoire courant. ls affiche les noms réels des fichiers présents.
Qui doit écrire décide du mode à poser
Faut-il écrire chmod 755 ou chmod u=rwx,go=rx ?
Les deux commandes posent le même rwxr-xr-x, le manuel GNU coreutils donnant l’équivalence entre 664 et ug=rw,o=r. Le mode octal fixe les trois rangs d’un coup et remplace tout ce qui n’est pas cité, le mode symbolique ne modifie que les rangs nommés. Pour retirer un seul droit sans recalculer le reste, chmod g-w rapport.txt vise le groupe et épargne les autres rangs.
Est-ce qu’un chmod -R 777 / est arrêté par défaut ?
Non. La page de manuel chmod(1) de coreutils 9.1 liste –no-preserve-root comme comportement par défaut et –preserve-root comme option à demander. Un parcours récursif lancé sur la mauvaise racine touche donc tout ce qu’il atteint, en ignorant les liens symboliques rencontrés. L’option –preserve-root, ajoutée à la commande, fait échouer un chmod -R dont la cible est la racine du système.
Comment remettre en 644 les fichiers d’un dossier sans toucher aux sous-dossiers ?
Deux commandes séparées traitent chaque type, comme l’écrit le wiki Archlinux dans sa section sur le chmod en masse : find dossier -type f -exec chmod 644 {} + pour les fichiers, puis find dossier -type d -exec chmod 755 {} + pour les répertoires. Une seule passe suffit quand il s’agit d’ajouter la lecture : chmod -R a+rX dossier, la lettre X ne posant l’exécution que sur les répertoires et les fichiers déjà exécutables, comme le définit chmod(1).
Pourquoi un répertoire en 644 refuse-t-il l’entrée ?
Parce que 644 ne contient aucun bit x, et que sur un répertoire x autorise la traversée. La page de manuel chmod(2) définit x comme le droit de chercher dans le répertoire, celui qui ouvre les entrées dont le nom est connu. Le wiki Archlinux ajoute qu’un répertoire sans x ne s’ouvre pas avec cd, et que son bit w ne sert à rien sans x. Pour un dossier lisible par tous mais modifiable par son seul propriétaire, la valeur usuelle est 755.
Pourquoi chmod ne change-t-il pas les droits d’un lien symbolique ?
Les permissions d’un lien symbolique ne sont pas utilisées : la page de manuel chmod(1) de coreutils 9.1 écrit que chmod ne les change jamais. Un lien nommé sur la ligne de commande fait donc agir chmod sur le fichier visé, tandis qu’un parcours récursif ignore les liens rencontrés. chmod 644 lien-vers-config.txt modifie les droits du fichier pointé, pas ceux du lien.
Sources
- Manuel GNU coreutils, section 27 « File permissions » (édition 9.12), www.gnu.org.
- Page de manuel chmod(1), coreutils 9.1-1, Debian bookworm, septembre 2022, manpages.debian.org.
- Page de manuel chmod(2), man-pages 6.19 du noyau Linux, février 2026, www.man7.org.
- Wiki Archlinux, « File permissions and attributes », wiki.archlinux.org.
- Dépôt du projet coreutils, fichier src/chmod.c, github.com.