## Introduction Les permissions de fichiers Linux contrôlent qui peut lire, écrire ou exécuter des fichiers et des répertoires. Lorsque vous obtenez une erreur « Permission denied », le chemin le plus rapide vers la résolution est un flux de travail clair et reproductible. Ce guide montre comment : - Identifier le chemin exact et l'opération qui échoue - Lire correctement les propriétaires et les modes - Utiliser chmod et chown en toute sécurité selon le principe du moindre privilège - Comprendre umask pour que les défauts soient corrects à la création des fichiers - Valider l'accès pour les services dans des conditions proches de la production ## Aperçu du flux de travail Utilisez cette séquence pour réduire le bruit et éviter le travail en double : - Reproduire et capturer l'échec - Notez la commande et le chemin : quel fichier ou répertoire, et quelle opération (lecture, écriture, exécution, listage, création, suppression). - Si le message est générique, tracez les appels système localement : strace -e trace=file -f -o /tmp/trace.log votre_commande - Recherchez EACCES ou EPERM et le chemin en échec. - Inspecter le chemin et ses parents - Affichez la cible et chaque répertoire parent : namei -l /chemin/vers/objet - Inspectez les détails : ls -ld /chemin /chemin/vers /chemin/vers/objet stat -c "%A %a %U:%G %n" /chemin/vers/objet - Vérifiez les options de montage qui peuvent bloquer l'exécution : findmnt -no TARGET,OPTIONS --target /chemin/vers/objet noexec bloque l'exécution de binaires ; nodev et nosuid affectent les bits device et suid. - Vérifiez l'attribut immuable (rare mais pénible) : lsattr /chemin/vers/objet S'il est positionné, supprimez-le avant d'écrire : chattr -i /chemin/vers/objet - Confirmer l'identité qui agit - Pour les shells interactifs : whoami id id -Gn - Pour un service : systemctl show -p User,Group,SupplementaryGroups votre.service ps -o user,group,egroup,egid= -C votre-binaire (ou par PID) - Décider du correctif minimal - Incohérence de propriétaire : préférez chown sur la plus petite arborescence, pas sur tout le système de fichiers. - Accès groupe manquant : utilisez un groupe partagé et positionnez setgid sur le répertoire. - Mode trop restrictif : ajoutez seulement les bits nécessaires (souvent g+rwX pour les collaborateurs). - Mode trop permissif : retirez l'accès « autres » ( o-rwx ) et reposez-vous sur utilisateur/groupe. - Définir les bons défauts - Si les nouveaux fichiers arrivent encore avec de mauvaises permissions, ajustez umask ou forcez l'héritage de groupe avec setgid sur les répertoires partagés. - Valider en tant qu'utilisateur visé sudo -u utilisateur_app -g groupe_app -- test -r /chemin && echo lisible sudo -u utilisateur_app -g groupe_app -- test -w /chemin && echo writable sudo -u utilisateur_app -g groupe_app -- test -x /chemin/vers/binaire && echo executable ## Diagnostiquer « Permission denied » La plupart des refus proviennent de l'une de trois causes : absence du bit d'exécution sur un répertoire qu'il faut traverser, absence de lecture ou d'écriture sur le fichier cible, ou un montage/attribut empêchant l'opération. Liste de contrôle : - Permission de traversée sur chaque répertoire parent : namei -l /srv/app/data/fichier.txt Assurez-vous du bit x sur chaque répertoire pour l'utilisateur ou le groupe qui agit. - Lecture/Écriture sur la cible finale : stat -c "%A %a %U:%G %n" /srv/app/data/fichier.txt - Échecs d'exécution : - Si c'est un script : assurez-vous du bit x sur le fichier, d'un shebang valide, et que l'interpréteur est exécutable. - Si le système de fichiers est monté noexec , les binaires ne s'exécuteront pas même avec x positionné. - Attributs et montages : - lsattr peut révéler des fichiers immuables ( i ) qui refusent les écritures. - findmnt montre des options comme noexec qui bloquent l'exécution. Exemple : Un script Python échoue avec « Permission denied ». namei -l montre que le répertoire parent /srv/app a le mode 750 et le groupe appdata , mais l'utilisateur n'appartient pas à ce groupe. Ajouter l'utilisateur à appdata et rouvrir une session corrige la traversée. ## Propriétaires, groupes et modes Les permissions sont évaluées dans cet ordre : - Bits propriétaire (utilisateur) u=rwx - Bits groupe g=rwx (si le processus appartient au groupe du fichier) - Bits autres o=rwx Points clés : - Répertoires : x permet la traversée, r liste les noms, w crée ou supprime des entrées. - Fichiers : r lit, w écrit, x exécute. - Le groupe effectif compte : assurez-vous que le processus est dans le groupe attendu ( id -Gn ). - Utilisez la portée minimale lors du correctif : opérez sur le chemin qui échoue réellement. Inspections utiles : ls -ld /srv/app /srv/app/data stat -c "%A %a %U:%G %n" /srv/app/data namei -l /srv/app/data/rapport.csv ## Utiliser chmod en toute sécurité Évitez les changements globaux. Préférez les modes symboliques qui expriment l'intention : - Accorder rw au propriétaire et r au groupe sur fichiers et répertoires, retirer « autres » : chmod -R u+rwX,g+rX,o-rwx /srv/app/data - Rendre un script exécutable par propriétaire et groupe : chmod ug+x /srv/app/bin/run.sh - Configurer un répertoire pour la collaboration : lecture, écriture et traversée pour le groupe : chmod 2770 /srv/partage Le 2 initial positionne setgid pour que les nouveaux fichiers héritent du groupe du répertoire. Référence numérique d'exemples : - Fichiers couramment 0644 ( rw-r--r-- ) ou 0660 ( rw-rw---- ) - Répertoires couramment 0755 ( rwxr-xr-x ) ou 0770 ( rwxrwx--- ) À éviter : - chmod -R 777 ... (surexpose les données et peut masquer de vrais problèmes de propriété) - Retirer l'exécution de répertoires qu'il faut encore traverser ## Utiliser chown et les groupes Les correctifs de propriété doivent correspondre aux responsabilités. - Définir propriétaire et groupe précisément : chown app:appdata /srv/app/data chown -R app:appdata /srv/app/data/logs # portée seulement sur ce qui est nécessaire - Créer et utiliser un groupe de collaboration : groupadd appdata usermod -aG appdata alice usermod -aG appdata app Les utilisateurs doivent rouvrir une session pour bénéficier du nouveau groupe (ou utiliser newgrp appdata ). - Forcer l'héritage de groupe dans les répertoires partagés : chmod g+s /srv/app/partage Les nouveaux fichiers obtiendront automatiquement le groupe du répertoire. - Créer des répertoires avec le bon propriétaire, groupe et mode en une étape : install -d -o app -g appdata -m 2770 /srv/app/partage ## Fondamentaux d'umask umask définit quels bits de permission sont retirés du défaut lors de la création de nouveaux fichiers ou répertoires. - Les fichiers démarrent à 0666 ; les répertoires à 0777 . - Mode effectif = base & ~umask - Exemples : - umask 022 → fichiers 0644 , répertoires 0755 - umask 027 → fichiers 0640 , répertoires 0750 - umask 002 → fichiers 0664 , répertoires 0775 (bon pour la collaboration de groupe) Définir umask : - Pour les shells interactifs : ajoutez umask 027 à ~/.profile ou /etc/profile . - Pour les services systemd : ajoutez UMask=0027 sous [Service] dans le fichier d'unité, puis : systemctl daemon-reload systemctl restart votre.service Astuce : Combinez UMask= avec un répertoire de projet setgid pour obtenir des défauts partagés prévisibles. ## Valider l'accès du service Les services s'exécutent souvent comme utilisateurs sans ouverture de session, donc testez toujours comme cette identité. - Découvrir l'utilisateur et les groupes du service : systemctl show -p User,Group,SupplementaryGroups votre.service - Vérifier le répertoire de travail, les données et les binaires : sudo -u app -g appdata -- test -r /srv/app/config.yml && echo lisible sudo -u app -g appdata -- test -w /srv/app/data && echo writable sudo -u app -g appdata -- test -x /srv/app/bin/run && echo executable - Vérifier les parents de chemin pour la traversée : sudo -u app -- namei -l /srv/app/data/rapport.csv - Confirmer que les montages ne bloquent pas l'exécution : findmnt -no TARGET,OPTIONS --target /srv/app/bin Si les permissions semblent correctes mais que les refus persistent, un système de contrôle d'accès obligatoire (comme SELinux ou AppArmor) peut être en cause. Cela dépasse ce guide sur les permissions de fichiers, mais les symptômes apparaissent souvent similaires. ## Plan pilote local Commencez petit pour pouvoir inspecter les résultats et revenir en arrière facilement. - Créer un utilisateur, un groupe et des répertoires de test groupadd appdata useradd -m -G appdata app install -d -o app -g appdata -m 2770 /srv/app-test/partage install -d -o app -g appdata -m 0750 /srv/app-test/logs - Définir les défauts avec umask pour la collaboration sudo -u app -- bash -c 'umask 002; touch /srv/app-test/partage/pilote.txt; mkdir /srv/app-test/partage/sous-rep' Vérifier que les nouveaux fichiers sont 0664 et les répertoires 0775 , et que le groupe est appdata : stat -c "%a %G %n" /srv/app-test/partage/pilote.txt /srv/app-test/partage/sous-rep - Valider les chemins d'accès sudo -u app -g appdata -- touch /srv/app-test/partage/pilote.txt namei -l /srv/app-test/partage/pilote.txt sudo -u app -g appdata -- test -w /srv/app-test/logs && echo logs writable - Exercer l'échec et le corriger chmod g-w /srv/app-test/logs sudo -u app -g appdata -- test -w /srv/app-test/logs || echo denied as expected chmod g+w /srv/app-test/logs Gardez un journal de commandes simple pour pouvoir reproduire ou annuler. - Documenter les commandes et résultats Lorsque le pilote se comporte comme prévu, appliquez les mêmes changements minimaux aux vrais chemins. ## Conclusion Utilisez un flux de travail systématique pour résoudre les erreurs « Permission denied » : - Identifier le chemin et l'opération qui échouent - Inspecter propriétaires, groupes et modes à chaque niveau de répertoire - Appliquer des changements chmod et chown minimaux avec le moindre privilège - Définir des défauts prévisibles avec umask (et setgid là où c'est utile) - Valider en tant que vrai utilisateur de service avant un déploiement plus large Commencez par un pilote local étroit, confirmez les résultats, puis étendez aux chemins de type production avec confiance.