Le journal grandit mais ne peut être recréé : vérifiez l’ACL du répertoire

Un journal qui ne cesse de grossir cesse de grossir à l’instant où quelque chose le recrée, et l’erreur indique permission refusée. La conclusion tentante est que le fichier lui-même a besoin de plus de permissions, alors que le même compte peut déjà y écrire. Ajouter à un nom existant et créer un nom nouveau sont deux contrôles différents, et seul le second interroge le répertoire.

Ajouter et créer sont deux contrôles différents

Ouvrir un fichier existant en ajout ne demande que le droit d’écriture sur ce fichier et le droit de parcours sur chaque répertoire de son chemin. Créer un fichier demande les droits d’écriture et de parcours sur le répertoire qui le contient, parce que l’opération y ajoute un nom. Remplacer un fichier par un renommage touche les deux répertoires et leurs règles de sticky bit.

Un descripteur déjà ouvert ajoute un quatrième cas. Un processus peut garder un descripteur en écriture ouvert avant d’avoir abandonné ses privilèges et échouer malgré tout à rouvrir le même chemin avec son identité ultérieure. Les ajouts réussis et la création manquée peuvent être vrais en même temps, pour le même processus.

Les ACL par défaut héritent, elles n’accordent pas

Une entrée commençant par le préfixe default décrit ce que les nouveaux objets héritent du répertoire. Elle n’accorde rien au répertoire lui-même et elle ne répare pas l’ACL d’un fichier qui existe déjà.

namei -l /var/log/openvpn/server.log
getfacl -p /var/log/openvpn
getfacl -p /var/log/openvpn/server.log

Lisez les entrées d’accès séparément des entrées par défaut, et lisez le masque. Une entrée nommée qui affiche des droits complets peut encore être limitée par le masque, c’est pourquoi le commentaire d’effectivité compte plus que les lettres de la première ligne.

Utilisez le chemin résolu plutôt que le chemin de la configuration. Un lien symbolique, un point de montage ou un répertoire tourné peuvent placer le vrai fichier là où la permission accordée n’arrive jamais. Parcourez le chemin d’abord avec namei, puis comparez chaque niveau au compte concerné. Deviner le répertoire de premier niveau, c’est ainsi qu’une correction atterrit un niveau trop haut.

Identifiez qui écrit à ce moment-là

Vérifiez l’unité de service, ses drop-ins et les paramètres de compte du démon avant de changer quoi que ce soit. Le processus qui ajoute et celui qui recrée peuvent être différents : un assistant de rotation, un écrivain d’état et un lecteur web partagent rarement une identité.

Une exécution de test depuis un shell root ne reproduit pas un service restreint, et elle réussira pendant que le service continue d’échouer. Reproduisez l’opération qui échoue sous la même unité, avec le même compte et les mêmes réglages de sandbox. Si vous n’y arrivez pas, démarrez l’unité avec un shell temporaire et vérifiez l’identité qu’elle rapporte. Tout le reste mesure votre terminal plutôt que le service.

Si la création est vraiment nécessaire, donnez à l’écrivain l’accès au répertoire de journal dédié et gardez l’accès en lecture des consommateurs séparé. Rendre inscriptible un compte partagé ou toute une arborescence d’application pour satisfaire un seul appel de journalisation échange un petit problème contre un gros.

Faites tourner sans réintroduire l’échec

Celui qui recrée le fichier décide de son propriétaire et de son mode pour le cycle suivant, alors coordonnez la correction avec la configuration de rotation. Un remplacement créé sous un autre compte, ou avec une ACL neuve, ramène l’échec après une correction réussie.

Fixez le mode et le groupe à la création, pas après, et vérifiez la rotation suivante plutôt que l’ajout suivant. Un ajout ne fait que répéter le test déjà réussi. Si l’outil de rotation propose un réglage de mode à la création, utilisez-le au lieu d’un chmod après coup. L’écart entre la création et le chmod est précisément le moment où l’écriture suivante peut échouer.

Quand la troncature échoue quand même, arrêtez d’ajouter des permissions

Un échec de troncature sur un fichier que vous pouvez écrire ne s’explique pas par les permissions du répertoire, et en ajouter davantage n’aidera pas. Regardez plutôt les attributs et le confinement : un attribut append-only n’autorise l’écriture qu’en mode ajout, et un montage en lecture seule ou un sandbox de service peut refuser une opération que l’ACL autorise.

Vérifiez les restrictions de système de fichiers de l’unité et les options de montage du chemin, puis reproduisez l’opération exacte qui a échoué. Élargir une permission qui n’a jamais été consultée ne fait que masquer quelle restriction était réelle. Retirez une restriction à la fois dans une unité jetable, et rétablissez-la avant de changer quoi que ce soit de permanent.