Droit de traversée sur chaque répertoire avant la clé

Le mode 0600 et le bon propriétaire ne garantissent pas que le service puisse ouvrir une clé. L’autorisation manquante se trouve généralement sur un répertoire au-dessus. Linux résout un chemin composant par composant, et chaque étape exige le droit de traversée avant que la suivante soit tentée. Lisez le chemin entier, pas la dernière ligne du listing.

Le droit de lecture est la dernière étape, pas la seule

Ouvrir un fichier demande au noyau de parcourir depuis la racine ou le répertoire de travail chaque composant du chemin. Un répertoire sans droit de traversée arrête ce parcours par une erreur de permission. Le mode du fichier lui-même n’est jamais consulté, si bien qu’une clé parfaitement lisible paraît illisible. L’erreur arrive souvent à l’ouverture sans nommer le répertoire, et c’est pourquoi le fichier final est mis en cause.

Pour un répertoire, le bit d’exécution signifie traversée, et non exécution du contenu. Une clé reste une donnée, et aucune partie de cette réparation n’exige de la marquer exécutable.

Parcourez le chemin en tant que compte de service

Listez chaque composant avec son propriétaire et son mode, puis répétez la lecture en tant qu’identité réelle du service. La différence entre votre shell et le démon est souvent toute la réponse. Suivez les liens symboliques jusqu’à la cible réelle, car c’est le chemin résolu qui est vérifié.

namei -l /etc/openvpn/client/office.key
sudo -u vpn-reader stat -c '%A %U:%G %n' /etc/openvpn/client/office.key

Un service peut aussi ouvrir des fichiers en plusieurs phases. Une partie du matériel est lue pendant la configuration privilégiée, tandis que d’autres fichiers sont ouverts après l’abandon des privilèges. Un shell root qui lit le fichier ne reproduit pas l’accès du worker ultérieur. Un espace de noms de montage peut présenter une autre vue du même chemin, surtout dans un conteneur, alors comparez la vue du système de fichiers du démon avec la vôtre.

Changez la permission la plus étroite qui convient

Choisissez le dispositif le plus petit qui donne accès au processus : un groupe contrôlé avec traversée sur les répertoires nécessaires, un emplacement géré que le service possède déjà, ou un autre mécanisme documenté. Lire un fichier n’exige pas de droit d’écriture sur son répertoire. Un large droit d’écriture de groupe sur une configuration privilégiée n’est pas une réparation normale de traversée. Un 0777 récursif n’est pas une solution non plus.

Notez quel composant vous avez changé et pourquoi. Un changement de permission sans raison consignée est difficile à relire et facile à oublier.

Regardez au-delà des modes seulement après le parcours

Si les bits de mode semblent suffisants, les contrôles restants sont les ACL, la politique de sécurité et les restrictions de sandbox. Une ACL peut accorder un accès que les bits de mode suggèrent absent, ou refuser un accès qu’ils semblent autoriser. Ces réglages appartiennent au propriétaire actuel de la configuration, et ils doivent être ajustés de façon étroite plutôt que désactivés. Une différence de racine ou de répertoire de travail peut aussi expliquer un chemin absolu qui fonctionne dans un contexte et échoue dans un autre.

Ne perdez pas de vue ce qu’est le fichier pendant que vous réparez l’accès. Un certificat CA est public par conception ; une clé privée ne l’est pas. Les fichiers que le client réécrit ont aussi besoin de droits d’écriture différents de ceux d’une clé d’identité en lecture seule. Inspectez les métadonnées sans imprimer de secrets, puis confirmez que le service lui-même fonctionne après le changement. Une courte note dans la documentation du service épargne le même parcours à la personne suivante.