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 à votre cas

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 jamais consultés. Sinon, si le groupe du fichier est l’un de vos groupes, vous obtenez la triade du groupe. Dans le cas contraire, vous obtenez la triade des autres utilisateurs.

Deux conséquences en découlent. La triade du propriétaire s’applique même lorsqu’elle est la plus restrictive. Un fichier dont le mode est 0466, affiché sous la forme -r--rw-rw-, donne uniquement le droit de lecture à son propriétaire, tandis que tous les autres peuvent écrire, car la vérification du propriétaire a réussi en premier et aucune règle suivante n’a été lue. C’est légal et cela déroute tout le monde lors de la première rencontre avec ce cas.

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

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 sous la forme drwxrwsr-x, et les fichiers créés à l’intérieur héritent alors du groupe du répertoire plutôt que du groupe personnel de leur créateur. La personne suivante peut ainsi continuer à les modifier. Donner à chaque service son propre compte 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 vos réglages. Il le reçoit du programme qui l’a créé, 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 la valeur 022. Un programme qui crée un fichier ordinaire demande le mode 0666. Un programme qui crée un répertoire demande le mode 0777. La umask efface 022 dans les deux cas. Les fichiers obtiennent donc le mode 644 et les répertoires le mode 755. C’est exactement la paire de valeurs que vous voyez 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 votre travail, mais personne d’autre ne le peut.

Deux limites sont importantes. La umask peut uniquement effacer des bits, jamais en ajouter. C’est pourquoi un fichier nouvellement créé n’est jamais exécutable, quelle que soit la valeur définie. De plus, un service systemd ne lit jamais votre profil shell. Définissez donc cette valeur dans le fichier d’unité.

[Service]
UMask=0027

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

Un serveur web s’exécute avec 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 d’y écrire, et un site statique ne devrait jamais l’y autoriser.

Le mode 644 sur un fichier donne l’écriture au propriétaire et la lecture à tous. L’utilisateur de déploiement peut donc publier les fichiers, et l’utilisateur web peut les servir. Le mode 755 sur un répertoire donne l’écriture au propriétaire et le droit de parcours à tous. L’utilisateur web peut ainsi parcourir le chemin sans pouvoir rien ajouter ni supprimer. Un bug dans l’application ne peut alors pas réécrire les pages qu’elle sert.

La règle de parcours pose souvent problème ici. Si le site se trouve dans /home/deploy/site et que /home/deploy est en 750, l’utilisateur web ne peut pas entrer dans le répertoire personnel. La requête se termine alors par une réponse 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

Le nombre 13 correspond à EACCES, le refus d’accès du noyau lié aux permissions. Le réseau ne présente aucun problème : le port est en écoute et la requête est bien arrivée. Cela rend le diagnostic déroutant lorsque vous apprenez encore le fonctionnement des ports en écoute sous Linux. Exécutez namei -l /home/deploy/site/index.html et parcourez la chaîne pour trouver le premier répertoire auquel il manque x pour les autres.

Un répertoire dans lequel l’application écrit, comme un chemin d’upload, constitue une exception. Accordez cet accès par la propriété plutôt qu’avec un mode plus permissif : sudo chown -R www-data:www-data /srv/site/uploads, et laissez 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 dispose pas du 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 à une autre erreur 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 noyau recherche alors un interpréteur nommé /bin/bash\r. Corrigez cela 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 est décrite dans la gestion des clés SSH et de leurs permissions de fichiers.

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é les permissions de son propre fichier de configuration et a refusé de s’exécuter. Ce fichier doit avoir les permissions 0440. C’est la conséquence classique d’un chmod récursif trop large. Cette erreur peut survenir en même temps que le message de sshd ci-dessus, ce qui fait de la console du fournisseur le seul moyen de rétablir l’accès.

Pourquoi 777 n’est pas une solution

777 donne un accès en écriture à tous les comptes de la machine et à tous les processus exécutés avec ces comptes. Un serveur exécute les services avec leurs propres comptes utilisateur. « 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 un répertoire web, les conséquences sont immédiates. Un répertoire accessible en écriture à tous et servi par le serveur transforme une faille d’upload en moyen de déposer un script, puis de l’exécuter en le demandant.

777 est presque toujours une 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 et empêche tous les autres comptes d’y accéder. La création de ces comptes avant tout déploiement fait partie de ces dix premières minutes sur un nouveau VPS.

L’écriture pour tous est légitime dans un emplacement bien connu, /tmp, et s’écrit drwxrwxrwt. Le dernier t 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 premier caractère d, avec le mode 755. Le triplet du propriétaire est rwx : le propriétaire dispose donc de toutes les permissions. Le triplet du groupe est r-x et celui des autres utilisateurs est r-x. Tous les autres utilisateurs peuvent donc lister les noms qu’il contient et traverser le répertoire, 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 alphabétique 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 traverser 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 la traversée à 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 d’élargir le mode pour tout le monde.

Le bit x signifie-t-il que je peux exécuter un répertoire ?

Non. Pour un répertoire, x signifie traversée. Il s’agit du droit de résoudre un nom à l’intérieur du répertoire lorsque le kernel parcourt un chemin. cd en a besoin, comme toute ouverture d’un fichier situé plus bas dans l’arborescence. Chaque répertoire du chemin doit disposer de x. Un fichier en mode 644 reste donc inaccessible si un répertoire situé au-dessus ne possède pas x pour vous. namei -l /path/to/file affiche le mode de chaque répertoire de la chaîne, ce qui indique où la résolution du chemin s’arrête.

chmod 777 est-il parfois 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 service compromis peut donc réécrire le fichier. Lorsqu’une application ne peut pas écrire dans un répertoire, le vrai problème concerne généralement le propriétaire : sudo chown -R appuser:appuser /srv/app/storage avec le mode 755 donne à l’application les droits nécessaires et empêche tous les autres utilisateurs d’y accéder en écriture. L’exception courante est /tmp en 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 ?

Ce 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é. 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 possède alors des droits que les trois triplets n’affichent pas. Exécutez getfacl <path> pour lister ces entrées supplémentaires.