Comment fonctionnent les permissions Unix : lire 755 sans deviner

Trois chiffres, trois parties, et une seule s'applique

Dans la sortie de `ls -l`, le premier caractère indique le type — un tiret pour un fichier ordinaire, d pour un répertoire, l pour un lien symbolique — et les neuf suivants forment trois groupes de trois : propriétaire, groupe, autres. Ce qui surprend, c'est que ces droits ne s'additionnent pas. Le noyau retient la première classe à laquelle tu appartiens et s'arrête là. Si tu es propriétaire d'un fichier en 477, tu obtiens r-- et rien d'autre, même si les bits du groupe et des autres sont grands ouverts : la classe propriétaire a correspondu en premier, le reste n'est jamais consulté.

Il y a deux façons d'écrire une modification, et elles ne sont pas équivalentes. L'octal est absolu : `chmod 644 notes.txt` fixe le mode entier et efface ce qui existait avant. Le symbolique est relatif : `chmod u+x script.sh` ajoute un bit et laisse les huit autres intacts. Dans un script de déploiement, tu veux presque toujours la forme octale, parce qu'elle produit le même état final quel que soit l'état du fichier à son arrivée.

Sur un répertoire, le bit d'exécution est un tout autre droit

Rien n'est jamais exécuté parce qu'on a donné le bit x à un répertoire. Sur un répertoire, ce bit est un droit de recherche : il permet à un processus de résoudre un nom à l'intérieur et d'atteindre ce qui se cache derrière. La séparation se voit facilement. Passe un répertoire en 400 et `ls` affichera volontiers les noms qu'il contient, mais chaque consultation échoue et `cat dir/fichier` est refusé — tu vois les étiquettes et ne touche à rien. Passe-le en 100 et c'est l'inverse : tu ne peux rien lister, mais si tu connais déjà le chemin exact, tu ouvres le fichier. Cette asymétrie explique qu'un répertoire personnel en 711 fonctionne : les autres atteignent ~/public_html sans pouvoir énumérer le reste.

La même logique explique un résultat qui ressemble à un bug. Supprimer un fichier n'est pas une modification du fichier : c'est une modification du répertoire qui le référence. La permission qui décide de la suppression est donc l'écriture plus l'exécution sur le répertoire contenant, et le mode du fichier lui-même n'y change rien. Un fichier en 444 placé dans un répertoire en 777 peut être supprimé par n'importe qui sur la machine. C'est précisément le trou que le sticky bit a été inventé pour boucher, d'où /tmp en 1777 plutôt qu'en 0777.

Le quatrième chiffre, et pourquoi umask n'est pas une permission

Trois bits spéciaux logent dans un chiffre de tête facultatif. Setuid vaut 4000 : sur un binaire exécutable, il fait tourner le programme avec l'identité du propriétaire — c'est ainsi que passwd modifie un fichier que tu ne peux pas toucher. Sous Linux il est ignoré en silence sur les scripts interprétés, et il n'a aucun sens sur un répertoire. Setgid vaut 2000 : sur un binaire il fait de même pour le groupe, et sur un répertoire il rend un service bien plus utile — les nouvelles entrées héritent du groupe du répertoire au lieu de celui du créateur, et les nouveaux sous-répertoires héritent aussi du bit setgid, façon standard de garder cohérente une arborescence de projet partagée. Le sticky vaut 1000 : sur un répertoire, il réserve la suppression et le renommage d'une entrée au propriétaire de l'entrée, au propriétaire du répertoire ou à root.

L'umask est la pièce qu'on inverse le plus souvent. Ce n'est pas la permission que reçoivent les nouveaux fichiers : c'est un masque de bits à retirer de ce que le programme créateur a demandé. Les programmes demandent 666 pour un fichier et 777 pour un répertoire, et chaque bit posé dans l'umask est désactivé. Avec l'umask courant 022, tu obtiens donc 644 pour les fichiers et 755 pour les répertoires. Et il efface plutôt qu'il ne soustrait : umask 023 donne toujours 644 sur un nouveau fichier, pas 643, parce que le fichier n'a jamais demandé le bit d'exécution et qu'il n'y a rien à retrancher. Autre parent proche : `chmod +x` sans lettre de classe n'équivaut pas à `chmod a+x`, car la forme nue respecte elle aussi ton umask — sous umask 077 elle n'accorde l'exécution qu'au propriétaire.

Questions fréquentes

Pourquoi chmod 777 est-il la mauvaise solution ?

Il donne un accès en écriture à tous les comptes de la machine, y compris à l'identité sous laquelle tourne ton serveur web ou un processus compromis, et un code accessible en écriture à tous est un code que n'importe qui peut remplacer. Il passe aussi le plus souvent à côté de la vraie cause, qui tient plus souvent à une mauvaise appartenance ou à un bit d'exécution manquant sur un répertoire parent qu'à une permission trop étroite. Certains logiciels refusent carrément de coopérer : OpenSSH ignore une clé privée ou un fichier authorized_keys accessible en écriture au groupe ou à tous.

chmod 755 rend-il un script exécutable ?

Il accorde la permission d'essayer, ce qui n'est pas la même chose que de le faire fonctionner. Un fichier texte a aussi besoin d'une ligne shebang désignant un interpréteur existant, sinon le noyau n'a rien à qui le confier. Deux autres éléments l'emportent totalement sur le mode : un système de fichiers monté avec l'option noexec refuse de lancer quoi que ce soit, quels que soient les bits, et chaque répertoire du chemin menant au fichier a besoin de son propre bit d'exécution pour que le fichier soit seulement atteignable.

Pourquoi quelqu'un peut-il supprimer un fichier que j'ai mis en lecture seule ?

Parce que la suppression modifie le répertoire, pas le fichier. Le noyau vérifie l'écriture et l'exécution sur le répertoire qui porte le nom, et ne regarde jamais le mode du fichier. Pour l'empêcher, resserre le répertoire ou pose-y le sticky bit, qui limite suppression et renommage au propriétaire de l'entrée, au propriétaire du répertoire et à root — la raison pour laquelle un /tmp partagé est en 1777.