Droits et permissions sous UNIX : chmod, chown, chgrp

« Permission denied » est sans doute le message d’erreur le plus rencontré sous Unix et Linux. Derrière lui se cache un système de droits simple dans son principe — trois catégories d’utilisateurs, trois permissions — mais dont la notation octale et quelques bits particuliers rebutent souvent.

Ce guide part de la lecture d’un ls -l, explique les deux notations de chmod, traite chown et chgrp, puis aborde les cas qui posent réellement problème : les droits sur les répertoires, le umask, les bits spéciaux et les valeurs à ne jamais utiliser sur un serveur exposé.

Lire les droits d’un fichier

Tout commence par ls -l :

ls -l rapport.txt
-rw-r--r-- 1 romain equipe 4096 12 oct. 09:14 rapport.txt

La première colonne se découpe en quatre parties :

• le premier caractère : le type. - pour un fichier, d pour un répertoire, l pour un lien symbolique ;
• les trois suivants : les droits du propriétaire — ici rw- ;
• les trois d’après : les droits du groupe — ici r-- ;
• les trois derniers : les droits de tous les autres — ici r--.

Viennent ensuite le propriétaire (romain) et le groupe (equipe). La lecture se fait donc ainsi : le propriétaire peut lire et écrire, les membres du groupe et tous les autres peuvent seulement lire.

Les trois permissions ont chacune une lettre et une valeur :

• r — lecture, valeur 4 ;
• w — écriture, valeur 2 ;
• x — exécution, valeur 1.

La notation octale

Ces valeurs s’additionnent par catégorie, ce qui donne un chiffre par groupe de trois, et trois chiffres au total.

Un 644 se lit donc : 6 pour le propriétaire (lecture et écriture), 4 pour le groupe (lecture), 4 pour les autres (lecture). C’est la valeur normale d’un fichier de données.

Un 755 ajoute le droit d’exécution : c’est la valeur d’un script ou d’un répertoire.

Les quatre valeurs qui couvrent la quasi-totalité des besoins :

• 644 : fichier ordinaire, lisible par tous ;
• 755 : script exécutable, ou répertoire ;
• 600 : fichier privé, lisible par son seul propriétaire — configuration contenant un mot de passe, clé privée ;
• 700 : répertoire privé.

chmod : modifier les droits

La forme octale est la plus directe :

chmod 644 rapport.txt
chmod 755 script.sh
chmod 600 config.ini

La forme symbolique permet de modifier un droit sans toucher aux autres, ce qui est souvent plus sûr :

chmod +x script.sh
chmod u+w fichier.txt
chmod g-w fichier.txt
chmod o-rwx secret.txt
chmod a+r public.txt

Les lettres avant le signe désignent la cible : u pour le propriétaire (user), g pour le groupe, o pour les autres (others), a pour tous (all). Sans lettre, +x s’applique à tous, filtré par le umask.

La différence pratique entre les deux notations : chmod 755 impose une valeur absolue et écrase tout, chmod +x ajoute une permission en laissant le reste intact. Sur un fichier dont vous ne connaissez pas les droits actuels, la seconde est plus prudente.

Appliquer récursivement, sans tout casser

L’option -R descend dans l’arborescence :

chmod -R 755 /var/www/site/

C’est presque toujours une mauvaise idée. Cette commande rend tous les fichiers exécutables, y compris les images, les feuilles de style et les fichiers de configuration. Sur un serveur web, c’est une faiblesse inutile.

La bonne méthode distingue fichiers et répertoires, en s’appuyant sur la commande find :

find /var/www/site/ -type d -exec chmod 755 {} \;
find /var/www/site/ -type f -exec chmod 644 {} \;

Plus rapide sur une grosse arborescence, en groupant les appels :

find /var/www/site/ -type d -print0 | xargs -0 chmod 755
find /var/www/site/ -type f -print0 | xargs -0 chmod 644

Il existe aussi une forme symbolique dédiée, le X majuscule, qui n’ajoute le droit d’exécution qu’aux répertoires et aux fichiers déjà exécutables :

chmod -R a+rX /var/www/site/

Le cas des répertoires

Sur un répertoire, les trois permissions n’ont pas le sens qu’on leur prête spontanément :

• r : pouvoir lister le contenu ;
• w : pouvoir créer, renommer ou supprimer des entrées ;
• x : pouvoir traverser le répertoire, c’est-à-dire accéder à ce qu’il contient.

Deux conséquences surprennent régulièrement.

Un répertoire en r-- permet de voir les noms des fichiers, mais pas de les ouvrir : sans le x, on ne peut pas traverser. À l’inverse, un répertoire en --x permet d’ouvrir un fichier dont on connaît le nom exact, sans pouvoir lister le contenu — un mécanisme parfois utilisé volontairement.

Et surtout : c’est le droit d’écriture sur le répertoire qui autorise à supprimer un fichier, pas les droits du fichier lui-même. Un fichier en lecture seule peut être supprimé par quiconque a le droit d’écrire dans le dossier qui le contient. C’est une source d’étonnement récurrente.

chown et chgrp : changer de propriétaire

chown modifie le propriétaire, et accessoirement le groupe :

chown romain fichier.txt
chown romain:equipe fichier.txt
chown :equipe fichier.txt
chown -R www-data:www-data /var/www/site/

chgrp ne fait que le groupe, et se révèle donc redondant avec la syntaxe à deux-points :

chgrp equipe fichier.txt

Une restriction importante : seul root peut donner un fichier à quelqu’un d’autre. Un utilisateur ordinaire ne peut pas céder la propriété de ses fichiers, même volontairement. La raison est une question de quota et de responsabilité : sans cette règle, on pourrait remplir le quota d’un autre.

Le cas concret le plus fréquent concerne les serveurs web. Les fichiers doivent appartenir à l’utilisateur du serveur — www-data sous Debian, apache ou nginx ailleurs — pour que celui-ci puisse écrire dans les dossiers de cache ou de téléversement. Une erreur d’attribution se traduit par des envois de fichiers qui échouent sans explication claire.

Le umask

Pourquoi un fichier créé arrive-t-il en 644 et non en 666 ? À cause du umask, un masque qui retire des droits aux valeurs par défaut.

umask
0022

Le calcul est une soustraction : les fichiers naissent théoriquement en 666 et les répertoires en 777 ; le umask retranche ses valeurs. Avec 022, on obtient 644 pour les fichiers et 755 pour les répertoires.

Un umask de 077 donne des fichiers en 600 et des répertoires en 700 — rien n’est accessible aux autres. C’est le réglage à adopter sur une machine partagée :

umask 077

La valeur n’est valable que pour la session courante. Pour la rendre permanente, ajoutez la ligne à votre ~/.bashrc ou ~/.profile.

Les bits spéciaux

Un quatrième chiffre, placé devant, active des comportements particuliers.

Le SUID (4000) fait exécuter un programme avec les droits de son propriétaire, et non de celui qui le lance. C’est ce qui permet à passwd, appartenant à root, de modifier le fichier des mots de passe quand un utilisateur ordinaire change le sien.

ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root ...

Le s à la place du x signale le SUID. C’est un mécanisme puissant et risqué : un programme SUID root mal écrit devient une porte d’entrée. N’en créez pas sans nécessité absolue.

Le SGID (2000) sur un répertoire fait hériter le groupe du dossier à tout ce qui y est créé. C’est la solution propre pour un dossier partagé entre plusieurs personnes :

chmod 2775 /partage/equipe/

Tous les fichiers créés dans ce dossier appartiendront au groupe du dossier, quels que soient les groupes par défaut de leurs auteurs.

Le sticky bit (1000) sur un répertoire limite la suppression au propriétaire de chaque fichier. C’est ce qui protège /tmp, où tout le monde écrit sans pouvoir effacer les fichiers des autres :

ls -ld /tmp
drwxrwxrwt 12 root root ...

Le t final le signale.

Ce qu’il ne faut jamais faire

chmod 777 donne tous les droits à tout le monde. C’est la réponse qu’on trouve partout sur les forums face à un « Permission denied », et c’est presque toujours la mauvaise.

Sur un serveur web, un fichier en 777 peut être modifié par n’importe quel processus de la machine — y compris un script malveillant déposé par une autre faille. Un fichier de configuration en 777 contenant vos identifiants de base de données est lisible par tous les comptes du serveur.

Quand un accès échoue, la bonne démarche est de comprendre qui a besoin d’écrire, puis d’attribuer le bon propriétaire ou le bon groupe. Dans neuf cas sur dix, un chown bien placé règle le problème qu’un chmod 777 ne ferait que masquer.

Le cas particulier des clés SSH illustre la logique inverse : OpenSSH refuse d’utiliser une clé privée dont les droits sont trop ouverts. Une clé doit être en 600 et son dossier en 700, faute de quoi la connexion échoue — voyez notre article sur les clés SSH pour le détail.

Diagnostiquer un refus d’accès

Quatre commandes, dans l’ordre :

id
ls -l fichier.txt
ls -ld /chemin/vers/le/dossier
namei -l /chemin/complet/vers/fichier.txt

id dit qui vous êtes et à quels groupes vous appartenez. Les deux ls donnent les droits du fichier et de son dossier. namei -l est le plus utile des quatre : il affiche les droits de chaque niveau du chemin, et révèle le répertoire intermédiaire qui bloque — cause fréquente et invisible autrement.

En résumé

• trois catégories — propriétaire, groupe, autres — et trois droits : r (4), w (2), x (1) ;
• 644 pour un fichier, 755 pour un script ou un répertoire, 600 pour un fichier sensible ;
• sur un répertoire, x signifie traverser et w permet de supprimer des fichiers qu’on ne possède pas ;
• jamais de chmod -R 755 sur un site : séparer fichiers et répertoires avec find, ou employer a+rX ;
• seul root peut changer le propriétaire d’un fichier ;
• umask 077 sur une machine partagée ;
• SGID pour un dossier d’équipe, sticky bit pour un dossier commun en écriture ;
• 777 n’est jamais la réponse : chercher le bon propriétaire plutôt que d’ouvrir à tous ;
• namei -l pour trouver le niveau qui bloque dans un chemin.