Les permissions Linux (chmod), expliquées sans jargon

Ce que ls -l vous dit vraiment

Lancez ls -l dans n'importe quel dossier Linux et la première colonne de chaque ligne ressemble à -rwxr-xr--. Cette chaîne fait dix caractères, et une fois qu'on sait comment la découper, elle cesse d'être du bruit. Le premier caractère indique le type d'élément — - pour un fichier normal, d pour un dossier. Les neuf autres se répartissent en trois groupes de trois : ce que le propriétaire peut faire, ce que le groupe peut faire, et ce que tous les autres peuvent faire. Chaque groupe de trois suit toujours le même ordre : lecture, écriture, exécution — r, w, x — un tiret signifiant "non autorisé".

Donc rwxr-xr-- signifie : le propriétaire peut lire, écrire et exécuter ; le groupe peut lire et exécuter mais pas écrire ; tout le monde d'autre peut seulement lire. Une fois qu'on sait lire cette chaîne d'un coup d'œil, la moitié du mystère autour de chmod disparaît déjà, parce que chmod n'est qu'une façon de régler ces neuf mêmes cases.

Ce que lecture, écriture et exécution veulent vraiment dire

Ces trois lettres signifient quelque chose de légèrement différent selon qu'on regarde un fichier ou un dossier, et c'est souvent là que naît la confusion.

Pour un fichier : la lecture permet de voir son contenu, l'écriture permet de le modifier ou de le supprimer, et l'exécution permet de le lancer comme programme ou script.

Pour un dossier, c'est moins intuitif : la lecture permet de lister ce qu'il contient (ls le dossier), l'écriture permet de créer ou supprimer des fichiers à l'intérieur, et l'exécution permet vraiment d'y entrer ou d'accéder à des fichiers par leur nom — même ceux dont on connaît déjà le chemin exact. C'est pourquoi on voit parfois un dossier sans permission de lecture mais avec l'exécution accordée : quelqu'un peut y faire cd et accéder à un fichier précis s'il sait qu'il existe, mais ne peut pas lister le reste. C'est une forme de confidentialité délibérée et étroite.

D'où viennent les chiffres de chmod

Les trois permissions par groupe ne sont pas arbitraires — ce sont des puissances de deux, ce qui explique pourquoi elles s'additionnent comme ça : lecture vaut 4, écriture vaut 2, exécution vaut 1. On additionne celles qui s'appliquent et on obtient un seul chiffre de 0 à 7 pour ce groupe. Toutes les permissions (lecture + écriture + exécution) donnent 4+2+1 = 7. Lecture et exécution seules donnent 4+1 = 5. Lecture seule donne 4. Aucune permission donne 0.

Une commande chmod donne toujours trois de ces chiffres à la suite — propriétaire, groupe, autres — donc chmod 754 script.sh signifie : le propriétaire obtient 7 (rwx, tout), le groupe obtient 5 (r-x, lire et exécuter mais pas modifier), tout le monde d'autre obtient 4 (r--, lecture seule). C'est exactement le même ensemble de permissions que rwxr-xr-- dans la sortie de ls -l. Une fois qu'on voit qu'un chiffre chmod à trois chiffres n'est que trois de ces totaux lecture/écriture/exécution mis côte à côte, on passe de "il faut mémoriser un tableau" à "je peux le calculer en cinq secondes", et c'est vraiment toute l'astuce.

Le mode symbolique, pour éviter le calcul

Les chiffres sont rapides une fois qu'on les connaît, mais Linux permet aussi de modifier les permissions symboliquement, ce qui est souvent plus clair pour une petite modification. chmod u+x script.sh ajoute la permission d'exécution pour l'utilisateur (le propriétaire) sans toucher au reste — la correction de permissions la plus courante que vous ferez jamais, généralement juste après avoir téléchargé ou écrit un script et obtenu une erreur Permission denied en essayant de le lancer. chmod go-w fichier.txt retire l'accès en écriture au groupe et aux autres, sans toucher aux permissions du propriétaire. Les lettres sont u (utilisateur/propriétaire), g (groupe), o (autres), et a (tous les trois) ; les opérateurs sont + pour ajouter, - pour retirer, et = pour définir exactement.

Pourquoi ça compte vraiment, au-delà de réussir un quiz

Les permissions sont le mécanisme qui rend un système multi-utilisateur sûr à utiliser. Sans elles, n'importe quel processus tournant sous n'importe quel utilisateur pourrait lire votre clé privée SSH, écraser les fichiers d'un autre utilisateur, ou modifier un binaire système dont dépend chaque programme de la machine. Quand vous voyez un avertissement disant que les permissions de votre fichier de clé SSH sont "trop ouvertes" et que SSH refuse de l'utiliser, ce n'est pas SSH qui fait des caprices — une clé privée lisible par d'autres utilisateurs de la machine annule tout l'intérêt qu'elle soit privée, donc SSH impose 600 (lecture/écriture pour le propriétaire uniquement, rien pour personne d'autre) comme exigence stricte plutôt que comme suggestion.

Ça explique aussi l'un des tickets de support les plus courants en début de carrière : un serveur web qui renvoie "403 Forbidden" pour un fichier qui existe manifestement. Neuf fois sur dix, ce n'est pas un bug de l'application — c'est un dossier quelque part dans le chemin qui manque de la permission d'exécution pour l'utilisateur sous lequel tourne le serveur web, ce qui empêche le serveur de simplement traverser le dossier pour atteindre le fichier, quelles que soient les permissions du fichier lui-même. Une fois qu'on a compris qu'un dossier a besoin de la permission d'exécution juste pour y entrer, cette erreur cesse d'être mystérieuse et se résout en cinq secondes avec un ls -ld.