Permission denied sous Linux : diagnostiquer le chemin et les ACL sans chmod 777

ParKelvin Carretero-Corrales

Une application renvoie Permission denied, alors que le fichier existe et que vous arrivez à le lire dans votre terminal. Avant de modifier les droits, vérifiez trois éléments : l’identité du processus, chaque répertoire du chemin et les éventuelles ACL. Le fichier final n’est qu’une partie du diagnostic.

Ce guide concerne Linux et les droits Unix avec les ACL de type POSIX. Les partages réseau et leurs modèles d’autorisation peuvent demander d’autres contrôles. Les commandes proposées consultent des métadonnées : elles ne changent ni les permissions ni le contenu des fichiers.

Commencer par l’opération réellement refusée

Notez le chemin exact, le message complet et l’action tentée : lire un fichier, l’exécuter, en créer un, ou remplacer un fichier existant. Ne rassemblez pas toutes ces opérations sous « l’application n’a pas accès » : leurs besoins ne sont pas identiques.

Conservez aussi l’heure et le contexte de l’échec. Dans un compte rendu, partagez seulement les extraits utiles ; masquez les noms ou chemins sensibles et ne recopiez pas le contenu d’un fichier de configuration pour prouver qu’il existe.

1. Vérifier l’identité du processus, pas celle du terminal

Une session d’administration et un service peuvent utiliser des identités différentes. Pour le processus concerné, remplacez PID par son identifiant numérique réel, obtenu avec votre outil de supervision ou votre gestionnaire de services :

cat /proc/PID/status

Repérez Uid:, Gid: et Groups:. Les deux premières lignes donnent, dans cet ordre, les identifiants réel, effectif, sauvegardé et utilisé pour le système de fichiers. La dernière liste les groupes supplémentaires. Comparez les identifiants du processus aux propriétaires et aux ACL des objets examinés.

Vérifiez que le PID correspond toujours au bon processus : un service peut avoir redémarré entre deux observations. Si la consultation est refusée, utilisez la procédure d’administration autorisée sur la machine ; ne contournez pas une restriction d’accès.

2. Examiner chaque composant avec namei

Adaptez ce chemin d’exemple à votre situation :

namei -l /srv/monapp/config/settings.yaml

namei -l déroule le chemin en affichant les modes, propriétaires et groupes. Il suit aussi les liens symboliques : regardez donc la destination réellement parcourue, pas seulement le chemin que vous aviez en tête.

Pour atteindre un fichier, le processus doit pouvoir traverser les répertoires parents : le droit x y correspond à la recherche, pas à l’exécution d’un programme. Un fichier lisible ne suffit pas si un parent bloque le passage.

Exemple fictif : settings.yaml autorise la lecture, mais /srv/monapp est réservé à son propriétaire. Un autre compte peut être bloqué avant même d’atteindre le fichier. Relisez les lignes dans l’ordre et cherchez le premier obstacle possible.

Attention : namei décrit ce que son propre processus peut observer. Une sortie complète depuis un terminal administrateur ne prouve pas que l’application bénéficie du même accès.

3. Lire les ACL et leur masque effectif

Les ACL permettent d’attribuer des droits à des utilisateurs ou groupes précis. Inspectez le fichier et les parents utiles, par exemple :

getfacl -p -e /srv /srv/monapp /srv/monapp/config /srv/monapp/config/settings.yaml

L’option -p conserve les chemins absolus et -e affiche les commentaires de droits effectifs. Si l’outil manque, référez-vous aux paquets et à la procédure de changement de votre distribution.

Voici une ACL fictive de fichier ; lecteurapp est un utilisateur nommé distinct du propriétaire :

user::rw-
user:lecteurapp:rw-     #effective:r--
group::r--
mask::r--
other::---

L’entrée nommée demande lecture et écriture, mais le masque ne laisse passer que la lecture. Ce masque limite les utilisateurs nommés, le groupe propriétaire et les groupes nommés ; il ne limite ni l’entrée du propriétaire ni other.

Une entrée utilisateur nommée qui correspond est examinée avant les entrées de groupe : on ne cumule pas simplement toutes les permissions visibles. Par ailleurs, lorsqu’un masque existe, les bits de groupe affichés par ls -l représentent ce masque, pas uniquement l’entrée group::.

Ne confondez pas ACL d’accès et ACL par défaut : les entrées default: d’un répertoire servent à initialiser les ACL des nouveaux objets. Les modifier ne corrige pas rétroactivement tous les fichiers déjà présents.

4. Pourquoi un chmod 777 peut masquer le problème

Le mode 777 ouvre les bits de lecture, écriture et exécution à toutes les classes d’utilisateurs. L’appliquer largement, surtout récursivement, donne des droits sans rapport avec le besoin initial. Un fichier de configuration à lire n’a pas nécessairement à être modifiable ou exécutable par tous.

Avec des ACL, modifier les bits de mode peut aussi changer les entrées correspondantes, notamment le masque. Une manipulation destinée à corriger un seul accès peut donc avoir des effets sur d’autres utilisateurs. Relisez l’état complet avant toute correction.

De même, un accès réussi en root n’est pas un test représentatif : les privilèges et capacités peuvent permettre de dépasser des contrôles de permissions classiques.

5. Si les droits semblent cohérents, vérifier le contexte

Le même nom de chemin ne désigne pas forcément la même vue du système de fichiers dans tous les processus. Un service isolé peut voir un environnement différent de votre terminal.

Avec systemd, des options comme InaccessiblePaths= peuvent masquer un chemin et ReadOnlyPaths= peut interdire l’écriture même si les droits Unix l’autorisent. Consultez la configuration effective et les journaux du service avant de conclure que les modes sont en cause. Ne désactivez pas globalement son isolation pour faire disparaître le symptôme.

Corriger un besoin précis, puis vérifier les limites

Une fois le blocage établi, préparez une correction limitée au compte, au répertoire ou à l’ACL concernés, avec conservation de l’état initial et possibilité de retour arrière. Le bon objectif n’est pas « plus aucune erreur », mais « l’opération prévue fonctionne, les accès inutiles restent refusés ».

  • Refaire l’opération avec le processus et le contexte réellement concernés.
  • Relire les droits et ACL après le changement, pas seulement avant.
  • Vérifier que les comptes non concernés n’ont pas reçu d’accès supplémentaire.
  • Tester, si le problème touche la création de fichiers, un nouvel objet dans un espace d’essai autorisé.
  • Documenter la cause, la correction et les contrôles réalisés.

À retenir

Devant un accès refusé, cherchez qui agit, quel chemin est parcouru et quelle règle s’applique. Cette démarche permet de justifier la correction. Élargir les droits au hasard fait seulement perdre une information utile : l’endroit exact où la protection a joué son rôle.

Sources

Publications similaires