Il log si accresce ma non viene ricreato: controlla l’ACL della directory

Un log che continua a crescere smette di crescere nel momento in cui qualcosa lo ricrea, e l’errore dice permesso negato. La conclusione tentante è che il file di log stesso abbia bisogno di più permessi, eppure il file potrebbe essere già scrivibile dallo stesso account. Aggiungere a un nome esistente e creare un nuovo nome sono due controlli diversi, e solo il secondo interroga la directory.

Aggiungere e creare sono controlli diversi

Aprire un file esistente per aggiungere richiede l’accesso in scrittura su quel file più l’accesso in ricerca lungo ogni directory del suo percorso. Creare un file richiede scrittura e ricerca sulla directory che lo contiene, perché l’operazione vi aggiunge un nome. Sostituire un file tramite rinomina tocca anche entrambe le directory e le loro regole sullo sticky bit.

Un descrittore già aperto aggiunge un quarto caso. Un processo può tenere un handle di scrittura aperto prima di aver lasciato i privilegi e comunque non riuscire a riaprire lo stesso percorso con la sua identità successiva. Le aggiunte riuscite e la creazione fallita possono essere entrambe vere, nello stesso momento, per lo stesso processo.

Le ACL predefinite ereditano, non concedono

Una voce che inizia con il prefisso predefinito descrive ciò che i nuovi oggetti ereditano dalla directory. Non concede nulla alla directory stessa e non ripara l’ACL di un file già esistente.

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

Leggi le voci di accesso separatamente da quelle predefinite, e leggi la maschera. Una voce con nome che elenca diritti completi può comunque essere limitata dalla maschera, per questo il commento effettivo conta più delle lettere della prima riga.

Usa il percorso risolto invece del percorso nella configurazione. Un collegamento simbolico, un punto di mount o una directory ruotata possono collocare il file reale dove il permesso concesso non arriva mai. Percorri prima il percorso con lo strumento dei nomi, poi confronta ogni livello con l’account in questione. Indovinare la directory di primo livello è il modo in cui una correzione atterra un livello troppo in alto.

Individua chi scrive in quel momento

Controlla l’unità di servizio, i suoi drop-in e le impostazioni dell’account del demone prima di cambiare qualcosa. Il processo che aggiunge e quello che ricrea possono essere diversi: un helper di rotazione, uno scrittore di stato e un lettore web raramente condividono un’identità.

Una prova eseguita da una shell root non riproduce un servizio limitato, e avrà successo mentre il servizio continua a fallire. Riproduci l’operazione fallita sotto la stessa unità, con lo stesso account e le stesse impostazioni di sandbox. Se non puoi, avvia l’unità con una shell temporanea e controlla l’identità che riporta. Qualsiasi altra cosa misura il tuo terminale, non il servizio.

Se la creazione è davvero necessaria, concedi allo scrittore l’accesso alla directory di log dedicata e tieni separato l’accesso in lettura per i consumatori. Rendere scrivibili un account condiviso o un intero albero applicativo per soddisfare una sola chiamata di logging scambia un piccolo problema con uno grande.

Ruota senza reintrodurlo

Chi ricrea il file decide proprietario e modo per il ciclo successivo, quindi coordina la correzione con la configurazione di rotazione. Una sostituzione creata con un altro account, o con un’ACL nuova, riporta il guasto dopo una correzione riuscita.

Imposta modo e gruppo alla creazione, non dopo, e verifica la rotazione successiva invece dell’aggiunta successiva. Un’aggiunta ripete solo la prova già superata. Se lo strumento di rotazione offre un’impostazione di modo di creazione, usala invece di un chmod dopo la creazione. L’intervallo tra creazione e chmod è esattamente quando la scrittura successiva può fallire.

Quando il troncamento fallisce comunque, smetti di aggiungere permessi

Il fallimento nel troncare un file che puoi scrivere non si spiega con i permessi della directory, e aggiungerne altri non aiuterà. Guarda invece gli attributi e il confinamento: un attributo append-only consente scritture solo in modalità append, e un mount in sola lettura o una sandbox di servizio possono negare un’operazione che l’ACL consente.

Controlla le restrizioni del filesystem dell’unità e le opzioni di mount del percorso, poi riproduci l’operazione esatta che è fallita. Ampliare un permesso che non è mai stato consultato nasconde solo quale restrizione era reale. Rimuovi una restrizione alla volta in un’unità usa e getta, e ripristinala prima di cambiare qualsiasi cosa permanente.