drwxr-xr-x : comprendre les permissions Linux

Ce que signifie drwxr-xr-x

drwxr-xr-x désigne un répertoire que son propriétaire peut modifier et que tous les autres utilisateurs peuvent lire et parcourir sans rien modifier. En notation octale, ce mode vaut 755. Linux affiche ces dix caractères au début de chaque ligne de la sortie de ls -l. Ils ont toujours la même signification et apparaissent toujours dans le même ordre. Apprendre une seule chaîne permet donc de comprendre toutes les autres.

Une règle s’applique avant toutes les autres, car elle détermine si vos propres tests sont concluants. L’utilisateur root ignore les bits de permission. Le noyau accorde à root la capacité CAP_DAC_OVERRIDE (contournement du contrôle d’accès discrétionnaire), ce qui permet à root d’ouvrir des fichiers dont le mode l’interdit. Tous les exemples de cette page réussissent avec root, quels que soient les bits affichés. Connectez-vous avec un utilisateur normal lorsque vous voulez observer le fonctionnement de ces règles.

Les dix caractères, un par un

Créez un répertoire et un fichier à examiner. Rien ici ne touche quoi que ce soit en dehors du nouveau répertoire.

mkdir -p ~/permdemo/inner
printf 'hello\n' > ~/permdemo/inner/notes.txt
ls -ld ~/permdemo ~/permdemo/inner ~/permdemo/inner/notes.txt

Avec l’umask courante par défaut, 022, les deux lignes du répertoire commencent par drwxr-xr-x et la ligne du fichier commence par -rw-r--r--.

Le caractère 1 indique le type de fichier, pas une permission. d est un répertoire. - est un fichier standard. l est un lien symbolique. c et b sont des nœuds de périphérique caractère et bloc. s est un socket et p est un tube nommé. Ce caractère est situé en dehors de la valeur octale. C’est pourquoi drwxr-xr-x devient 755 au lieu de commencer par d.

Les neuf caractères suivants sont répartis en trois groupes de trois. Leur ordre ne change jamais.

• Les caractères 2 à 4 forment le triplet du propriétaire. Ils correspondent à l’utilisateur qui possède le fichier.
• Les caractères 5 à 7 forment le triplet du groupe. Ils correspondent au groupe du fichier.
• Les caractères 8 à 10 forment le triplet des autres utilisateurs. Ils correspondent à tous les autres utilisateurs.

Dans un triplet, les positions sont toujours r, puis w, puis x. Un tiret signifie que le bit est désactivé. Les lettres restent toujours à la même position. r-x signifie que la lecture est autorisée sans l’écriture. -w- signifie que l’écriture est autorisée sans la lecture. Cette combinaison est valide, mais rare.

Ainsi, drwxr-xr-x se découpe comme suit : d pour le répertoire, puis rwx pour le propriétaire, r-x pour le groupe et r-x pour les autres utilisateurs.

Certains systèmes affichent un onzième caractère. Un point final, drwxr-xr-x., signifie que le fichier possède un contexte SELinux (security enhanced Linux). Les distributions qui utilisent SELinux, comme Fedora et Rocky, l’affichent par défaut. Un plus final, drwxr-xr-x+, signifie que le fichier possède une ACL POSIX (access control list), c’est-à-dire un ensemble supplémentaire de règles en plus de ces neuf bits. Affichez ces règles supplémentaires avec getfacl <path>.

r, w et x ont des fonctions différentes sur un répertoire

C’est la première règle que les débutants comprennent mal. Les lettres sont les mêmes pour un fichier et pour un répertoire. Les droits qu’elles accordent ne le sont pas.

• r sur un fichier permet de lire son contenu. r sur un répertoire permet d’afficher les noms qu’il contient, ce dont `ls` sans option a besoin.
• w sur un fichier permet de modifier son contenu. w sur un répertoire permet d’y ajouter et d’en supprimer des entrées. Supprimer un fichier revient à modifier le répertoire. C’est donc le droit d’écriture du répertoire qui décide, et le mode du fichier lui-même n’intervient pas.
• x sur un fichier permet de l’exécuter comme un programme. x sur un répertoire permet de le parcourir. Le kernel peut ainsi résoudre un nom qui s’y trouve pendant la résolution d’un chemin.

Le parcours est la partie qui surprend le plus souvent. x sur un répertoire n’exécute rien. Pour ouvrir /srv/site/index.html, il faut x sur /, puis x sur /srv, puis x sur /srv/site, et enfin r sur le fichier. Si un répertoire de cette chaîne ne vous accorde pas x, la résolution s’arrête à cet endroit. Le programme appelant reçoit alors Permission denied pour l’ensemble du chemin, même si le fichier final est lisible par tous. namei -l /srv/site/index.html affiche chaque étape de la chaîne avec son mode et son propriétaire. Vous pouvez ainsi voir quel élément bloque la résolution.

Un répertoire avec r mais sans x constitue un état intermédiaire inhabituel qu’il est utile de reconnaître. Un utilisateur ordinaire peut afficher les noms, car c’est ce que permet r, mais il ne peut pas obtenir les informations d’aucune entrée. `ls -l remplit donc les colonnes de taille et de mode avec des points d’interrogation et affiche ls: cannot access ...: Permission denied` pour chacune d’elles.

Convertir les lettres en 755

Chaque triade est un nombre de trois bits. r vaut 4, w vaut 2 et x vaut 1. Additionnez les bits activés.

• rwx vaut 4 + 2 + 1 = 7
• rw- vaut 4 + 2 = 6
• r-x vaut 4 + 1 = 5
• r-- vaut 4
• --- vaut 0

drwxr-xr-x vaut donc 7 pour le propriétaire, 5 pour le groupe et 5 pour les autres utilisateurs : 755. -rw-r--r-- vaut 6, 4, 4 : 644. drwxrwxr-x vaut 7, 7, 5 : 775, soit 755 avec le droit d’écriture ajouté pour le groupe. Vous n’avez jamais besoin de compter les caractères manuellement, car stat affiche les deux formes simultanément.

stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt

%A est la forme avec des lettres, %a est la forme octale, et %U et %G indiquent l’utilisateur propriétaire et le groupe propriétaire.

Les chaînes de permissions que l’on recherche le plus souvent

Voici les modes que vous rencontrez sur un serveur réel, avec leur valeur octale et les cas où ils sont utilisés.

• -rw-r--r-- correspond à 644. Fichiers ordinaires qu’un service lit uniquement, comme un fichier de configuration ou une page HTML.
• -rw------- correspond à 600. Secrets : une clé privée SSH ou le fichier .env d’une application.
• -rw-rw-r-- correspond à 664. Fichier situé dans un répertoire partagé par un groupe, lorsque les membres de l’équipe doivent pouvoir y écrire.
• -rwxr-xr-x correspond à 755. Scripts et binaires, comme /usr/local/bin/backup.sh et la plupart de /usr/bin.
• -rwx------ correspond à 700. Script privé que seul son propriétaire peut exécuter.
• drwxr-xr-x correspond à 755. Presque tous les répertoires système et la racine documentaire d’un site web.
• drwx------ correspond à 700. ~/.ssh et les répertoires personnels sur un serveur dont l’accès est strictement limité.
• drwxrwxr-x correspond à 775. Répertoire dans lequel le groupe du propriétaire peut écrire.
• drwxrwsr-x correspond à 2775. Même configuration, avec en plus le bit setgid : les nouveaux fichiers qu’il contient héritent du groupe du répertoire.
• drwxrwxrwt correspond à 1777. /tmp. Le dernier t est le sticky bit : un utilisateur ne peut supprimer que ses propres fichiers.
• -rwsr-xr-x correspond à 4755. Binaire setuid qui s’exécute avec les droits de son propriétaire, comme /usr/bin/passwd et /usr/bin/sudo.
• -rw-rw-rw- correspond à 666 et drwxrwxrwx correspond à 777. Ces permissions autorisent l’écriture à tout le monde, ce qui constitue presque toujours une erreur sur un serveur.
• lrwxrwxrwx est ce qu’affiche tout lien symbolique. Linux ignore les bits de mode d’un lien et vérifie ceux de la cible. Cette chaîne n’a donc aucune signification.

Quelle triade s’applique à vous

Voici la deuxième règle que les débutants comprennent souvent mal. Le kernel sélectionne exactement une triade, puis s’arrête.

Si votre identifiant utilisateur correspond au propriétaire du fichier, vous obtenez la triade du propriétaire. Les bits du groupe et des autres utilisateurs ne sont alors jamais consultés. Sinon, si le groupe du fichier fait partie de vos groupes, vous obtenez la triade du groupe. Dans tous les autres cas, vous obtenez la triade des autres utilisateurs.

Deux conséquences en découlent. La triade du propriétaire s’applique même lorsqu’il s’agit de la plus restrictive. Un fichier en mode 0466, affiché comme -r--rw-rw-, donne uniquement le droit de lecture à son propriétaire, tandis que tous les autres peuvent écrire. Le contrôle du propriétaire a correspondu en premier et aucun autre bit n’a été consulté. C’est légal et cela déroute généralement la première fois.

La triade du groupe est ensuite sélectionnée à partir du groupe du fichier, et non de la liste des groupes auxquels vous appartenez. ls -l affiche deux noms sur chaque ligne : le propriétaire, puis le groupe. Seul ce second groupe intervient pour ce fichier. Appartenir à vingt groupes n’est utile que si le fichier porte l’un d’eux.

id
stat -c '%U %G %A %n' ~/permdemo/inner/notes.txt

id affiche votre utilisateur et tous les groupes auxquels vous appartenez. stat affiche le propriétaire et le groupe du fichier. Comparez les deux pour savoir quelle triade le kernel utilisera pour vous.

C’est pourquoi un répertoire partagé reçoit généralement un groupe et le bit setgid. sudo chmod 2775 /srv/shared s’affiche comme drwxrwsr-x. Les fichiers créés à l’intérieur héritent alors du groupe du répertoire au lieu du groupe personnel de leur créateur. Les nouveaux sous-répertoires reçoivent également le bit setgid. Setgid définit le groupe, pas le mode. Avec l’umask par défaut 022, un nouveau fichier créé dans ce répertoire conserve le mode 644. Les membres de l’équipe peuvent donc le lire, mais pas l’écrire. Le droit d’écriture pour le groupe nécessite une umask à 002 pour toutes les personnes qui y travaillent, ou une ACL par défaut sur le répertoire. Celle-ci remplace l’umask pour les fichiers qui y sont créés. Attribuer un compte distinct à chaque service constitue l’autre aspect de cette configuration. Il est présenté dans un utilisateur Linux par service sur un VPS.

umask détermine le mode de chaque nouveau fichier

Un nouveau fichier ne reprend pas son mode depuis votre session. Il le reçoit du programme qui le crée, après suppression des bits effacés par votre umask. La umask est un masque de bits à supprimer. Plus sa valeur est élevée, plus les fichiers sont privés.

La plupart des distributions utilisent 022. Un programme qui crée un fichier standard demande généralement 0666. Un programme qui crée un répertoire demande généralement 0777. La umask supprime 022 de ces deux valeurs. Les fichiers obtiennent donc 644 et les répertoires 755. C’est exactement le couple de valeurs que vous trouvez sur un VPS fraîchement installé.

umask
umask -S
touch ~/permdemo/new.txt && mkdir -p ~/permdemo/newdir
ls -ld ~/permdemo/new.txt ~/permdemo/newdir

umask -S affiche la même valeur sous forme de lettres, ce qui est plus lisible que 0022. Définissez umask 027 dans ~/.profile pour appliquer une valeur par défaut plus stricte : 640 pour les fichiers et 750 pour les répertoires. Votre groupe peut ainsi lire vos fichiers, mais aucun autre utilisateur ne le peut. Ces résultats supposent les demandes habituelles 0666 et 0777.

Deux limites sont importantes. La umask peut uniquement supprimer des bits, jamais en ajouter. Un fichier demandé avec le mode 0666, ce que demande touch, ne devient jamais exécutable, quelle que soit votre configuration. De même, un programme qui demande un accès réservé au propriétaire le conserve : mktemp crée des fichiers avec le mode 600 et des répertoires avec le mode 700, avec une umask de 022 comme de 027. En outre, un service systemd ne lit jamais votre profil shell. Définissez donc la valeur dans le fichier d’unité.

[Service]
UMask=0027

Un cas ignore complètement la umask. Lorsque le répertoire parent possède une ACL par défaut, la umask est ignorée et les bits de permission du nouveau fichier proviennent de l’ACL héritée.

Pourquoi les fichiers web sont en 644 et les répertoires web en 755

Un serveur web s'exécute sous son propre compte, www-data sur Debian et Ubuntu, nginx sur Rocky et Alma. Ce processus doit pouvoir lire les fichiers qu'il sert et parcourir les répertoires qui les contiennent. Il n'a aucune raison de les modifier, et un site statique ne devrait jamais l'autoriser.

Le mode 644 sur un fichier donne l'écriture au propriétaire et la lecture à tout le monde, permettant ainsi à l'utilisateur de déploiement de publier et à l'utilisateur web de servir le contenu. Le mode 755 sur un répertoire donne l'écriture au propriétaire et le droit de parcours à tout le monde, permettant à l'utilisateur web de traverser le chemin sans pouvoir ajouter ou supprimer quoi que ce soit. Un bug dans l'application ne peut alors pas réécrire les pages qu'elle sert.

La règle de parcours s'applique précisément ici. Si le site est situé dans /home/deploy/site, que /home/deploy est en 750, et que l'utilisateur web n'appartient pas au groupe du répertoire, l'utilisateur web ne peut pas entrer dans le répertoire personnel. La requête se termine par une erreur HTTP 403 avec une ligne comme celle-ci dans /var/log/nginx/error.log :

open() "/home/deploy/site/index.html" failed (13: Permission denied), client: 203.0.113.5

Ce 13 correspond à EACCES, le refus de permission du noyau. Le réseau fonctionne correctement : le port est en écoute et la requête est bien arrivée, ce qui rend cette situation déroutante lorsque vous apprenez comment fonctionnent les ports en écoute sous Linux. Exécutez namei -l /home/deploy/site/index.html et remontez la chaîne pour identifier le premier répertoire sans le droit x pour les autres utilisateurs.

Un répertoire dans lequel l'application écrit, comme un chemin de téléchargement, constitue l'exception. Gérez cela par la propriété plutôt que par un mode plus large : sudo chown -R www-data:www-data /srv/site/uploads et conservez le mode 755. Limitez l'accès en écriture au seul répertoire qui en a besoin.

chmod, sans aplatir toute l’arborescence

chmod accepte les deux formes. La forme octale définit les neuf bits en une seule fois : chmod 644 notes.txt. La forme symbolique ne modifie que les droits indiqués et laisse les autres inchangés : chmod u+x deploy.sh ajoute le droit d’exécution pour le propriétaire, tandis que chmod go-w notes.txt retire le droit d’écriture au groupe et aux autres utilisateurs.

La récursion est la principale cause de dégradation des arborescences. chmod -R 755 . rend exécutables toutes les images et tous les fichiers de configuration, car chmod ne sait pas distinguer un script d’un fichier JPEG. Utilisez plutôt le X majuscule.

chmod -R u=rwX,go=rX ~/permdemo
stat -c '%a %n' ~/permdemo ~/permdemo/inner/notes.txt

Le X majuscule applique le droit d’exécution aux répertoires et aux fichiers qui possédaient déjà un bit d’exécution. Les répertoires obtiennent les droits 755, les fichiers ordinaires les droits 644, et les scripts qui étaient déjà exécutables le restent. Lorsqu’un fichier possède déjà un mode fiable, chmod --reference=good.sh other.sh le recopie sur les autres fichiers.

Les messages affichés lorsqu’un élément est incorrect

bash: ./deploy.sh: Permission denied signifie que le script ne possède pas le bit x dans le triplet qui s’applique à votre compte, ou qu’un répertoire de son chemin ne possède pas le bit x. chmod u+x deploy.sh corrige le premier cas.

bash: ./deploy.sh: cannot execute: required file not found correspond à un autre problème, au nom trompeur. Le bit x est correct, mais l’interpréteur indiqué sur la première ligne est introuvable. La cause habituelle est l’utilisation de fins de ligne Windows : le kernel recherche alors un interpréteur nommé /bin/bash\r. Corrigez le problème avec sed -i 's/\r$//' deploy.sh.

Permissions 0644 for '/home/deploy/.ssh/id_ed25519' are too open. est généré par le client SSH, qui refuse d’utiliser une clé privée lisible par d’autres comptes. La clé doit avoir les permissions 600 et ~/.ssh doit avoir les permissions 700. La gestion complète des clés SSH est décrite dans la gestion des clés SSH et de leurs permissions.

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh apparaît dans le journal du serveur lorsqu’un répertoire personnel ou son .ssh est accessible en écriture par le groupe. Le paramètre StrictModes de sshd rejette la clé. Côté client, cela se traduit par une demande de mot de passe inattendue, sans explication.

sudo: /etc/sudoers is world writable, suivi de sudo: no valid sudoers sources found, quitting, signifie que sudo a vérifié le mode de son propre fichier de configuration et a refusé de s’exécuter. Ce fichier doit avoir les permissions 0440 et ne doit jamais être accessible en écriture à tous les utilisateurs. C’est la conséquence classique d’un chmod récursif trop large. Le problème peut survenir en même temps que le message de sshd ci-dessus, ce qui laisse la console du fournisseur comme seul moyen de récupérer l’accès au serveur.

Pourquoi 777 ne résout pas le problème

777 accorde un accès en écriture à tous les comptes de la machine et à tous les processus exécutés sous ces comptes. Un serveur exécute les services avec leurs propres utilisateurs. Le terme « tout le monde » couvre donc beaucoup plus de comptes sur un VPS que sur un ordinateur portable. Un service compromis peut écrire partout où 777 l’autorise.

Dans une racine web, les conséquences sont directes. Un répertoire accessible en écriture à tous et également servi par le serveur transforme une faille d’upload de fichiers en possibilité de déposer un script, puis de le demander au serveur.

777 est presque toujours la mauvaise réponse à un problème de propriété. Le symptôme est le suivant : « l’application ne peut pas écrire dans ce répertoire ». La cause est que le répertoire appartient au mauvais utilisateur. sudo chown -R appuser:appuser /srv/app/storage avec le mode 755 résout le problème : l’application peut y écrire, tandis que les autres comptes peuvent toujours lister le répertoire et y entrer, mais ne peuvent pas y écrire. La création de ces comptes avant tout déploiement fait partie des dix premières minutes sur un nouveau VPS.

L’écriture pour tous est légitime dans un emplacement courant, /tmp, et s’écrit drwxrwxrwt. Le t final est le sticky bit : le répertoire est accessible en écriture à tous, mais un utilisateur ne peut supprimer que les fichiers qui lui appartiennent. Sans ce bit, n’importe quel compte pourrait supprimer les fichiers temporaires d’un autre compte.

Lire un mode avant de le modifier

Ces commandes lisent uniquement l’état du système. Vous pouvez donc les exécuter n’importe où sans risque.

id
umask
stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt
namei -l ~/permdemo/inner/notes.txt
find ~/permdemo -perm -0002

find <path> -perm -0002 répertorie, sous un chemin donné, tous les éléments dont le bit d’écriture pour les autres utilisateurs est défini. C’est le moyen le plus rapide d’auditer un serveur après des réparations effectuées avec chmod 777.

Pour vérifier si un compte de service peut entrer dans un répertoire, effectuez le test avec ce compte. sudo -u www-data test -x /srv/site && echo yes || echo no affiche yes lorsque cet utilisateur dispose du droit de traversée sur le répertoire, et no dans le cas contraire. Effectuer le test en tant que root ne prouve rien : root contourne ce contrôle et la réponse est toujours yes.

FAQ

Que signifie drwxr-xr-x sous Linux ?

Il s’agit d’un répertoire, indiqué par le d initial, avec le mode 755. La triade du propriétaire est rwx : le propriétaire dispose donc de toutes les permissions. La triade du groupe est r-x et celle des autres utilisateurs est r-x. Tous les autres utilisateurs peuvent donc lister les noms qu’il contient et le parcourir, mais seul le propriétaire peut y ajouter ou supprimer des éléments. Vérifiez n’importe quel chemin avec stat -c '%A %a %U %G %n' <path>, qui affiche côte à côte la forme avec lettres et la forme octale.

Pourquoi les fichiers web sont-ils en 644 et les répertoires web en 755 ?

Le serveur web s’exécute avec un autre compte, www-data sur Ubuntu. Il doit pouvoir lire les fichiers qu’il sert et parcourir chaque répertoire situé au-dessus d’eux. Il n’a aucune raison d’écrire dans ces fichiers ou répertoires. Le mode 644 donne l’écriture au propriétaire et la lecture à tous les autres utilisateurs. Le mode 755 donne l’écriture au propriétaire et le droit de parcours à tous les autres utilisateurs. Un répertoire dans lequel l’application doit réellement écrire doit être attribué avec chown à l’utilisateur de cette application, plutôt que de donner des permissions plus larges à tout le monde.

Le bit x permet-il d’exécuter un répertoire ?

Non. Pour un répertoire, x signifie le droit de parcours : il permet de résoudre un nom à l’intérieur du répertoire lorsque le kernel parcourt un chemin. cd en a besoin, tout comme chaque ouverture d’un fichier situé sous ce répertoire. Chaque répertoire du chemin doit disposer de x. Ainsi, un fichier en mode 644 reste inaccessible si un répertoire situé au-dessus ne vous accorde pas x. namei -l /path/to/file affiche le mode de chaque répertoire du chemin, ce qui indique à quel endroit la résolution s’arrête.

chmod 777 peut-il parfois être la bonne solution ?

Presque jamais sur un serveur. Ce mode accorde l’écriture à tous les comptes de la machine, y compris aux comptes utilisés par les services. Un seul service compromis peut donc réécrire le fichier. Lorsqu’une application ne peut pas écrire dans un répertoire, le vrai problème est généralement la propriété : sudo chown -R appuser:appuser /srv/app/storage avec le mode 755 donne à l’application le droit d’écriture, tandis que les autres comptes peuvent toujours lire le répertoire sans y écrire. L’exception courante est /tmp avec le mode 1777. Cela fonctionne uniquement parce que le sticky bit empêche les utilisateurs de supprimer les fichiers des autres.

Pourquoi ls affiche-t-il un point ou un signe plus après les permissions ?

Le onzième caractère décrit des règles qui s’ajoutent aux neuf bits de permission. Un point, comme dans drwxr-xr-x., signifie qu’un contexte de sécurité SELinux est associé au fichier. C’est normal sur Fedora et Rocky. Un signe plus, comme dans drwxr-xr-x+, signifie qu’une ACL POSIX (liste de contrôle d’accès) est définie. Un utilisateur ou un groupe dispose alors de droits qui n’apparaissent pas dans les trois triades. Exécutez getfacl <path> pour afficher ces entrées supplémentaires.