PrivateTmp: l’hook ha scritto il file, ma dov’è finito?

Gli hook segnalano un successo, e lo stesso percorso sembra ancora vuoto da una shell. Entrambe le affermazioni possono essere vere insieme, perché un servizio systemd può vivere nel proprio spazio dei nomi di mount con una directory temporanea privata. Una volta capito questo, la domanda interessante diventa se la scrittura sia riuscita davvero.

Due directory temporanee, un solo percorso

L’impostazione di isolamento dà all’unità una vista privata delle directory temporanee invece di renderle di sola lettura. I processi fuori dall’unità non possono vedere ciò che vi scrive, e tutto ciò che lascia dietro viene scartato quando l’unità si ferma. Un percorso stampato dall’hook e un percorso controllato da una shell possono quindi riferirsi a oggetti diversi con lo stesso nome.

È un problema di visibilità, e sembra un problema di perdita di dati. Non è stato cancellato nulla, perché il file si trova semplicemente in uno spazio dei nomi di cui la shell non fa parte. Lo stesso comando si comporta diversamente quando viene eseguito dentro l’unità, ed è questa l’osservazione che di solito risolve la discussione. Leggi le impostazioni dell’unità prima di concludere qualcosa sulla scrittura.

Separa l’invisibile dall’impossibile da scrivere

Una scrittura riuscita e un’apertura fallita producono prove diverse, e questa distinzione decide la riparazione. Se l’hook dice che il file è stato creato ma un lettore esterno non lo trova, hai una questione di spazio dei nomi. Se l’hook segnala un errore di permessi o un’apertura fallita, il file non è mai stato scritto e nessun cambiamento dello spazio dei nomi aiuterà.

systemctl show [email protected] -p PrivateTmp -p User -p Group -p RuntimeDirectory
systemctl show [email protected] -p MainPID --value
sudo ls -l /proc/PID/root/tmp/client-state

Il percorso della radice del processo espone la vista del file system del servizio stesso, soggetta ai controlli dei permessi su quel processo finché è ancora in esecuzione. Leggi il journal dell’unità nella stessa sessione, perché un errore di scrittura e un file mancante si confondono facilmente quando qualcuno ha già deciso la causa.

Dai ai dati condivisi una posizione esplicita

I dati di cui ha bisogno solo il servizio appartengono alla sua directory temporanea privata. I dati che un altro processo deve leggere richiedono un percorso definito per entrambi, con proprietario, modalità e scadenza dichiarati. Decidi quale dei due casi hai prima di modificare l’unità. La maggior parte di questi incidenti nasce dal trattare un file privato come condiviso.

[Service]
RuntimeDirectory=openvpn-hook-office
RuntimeDirectoryMode=0750

Una directory di runtime colloca la cartella sotto l’area di runtime del sistema, la crea per l’utente e il gruppo configurati dell’unità e la rimuove quando l’unità si ferma. Aggiungila tramite un drop-in in modo che l’unità del pacchetto resti intatta, poi ricarica il gestore e riavvia quell’istanza, accettando che i suoi client si riconnettano.

Conserva qualsiasi directory di runtime che l’unità installata richieda già. Sostituire l’elenco invece di aggiungervi è un modo comune di rompere una funzione non correlata che nessuno collega alla modifica.

Due livelli di privilegi possono non essere d’accordo

Il gestore dei servizi crea la directory per l’utente configurato dell’unità, mentre il demone VPN può scendere separatamente al proprio account prima di eseguire un hook di connessione. Sono livelli diversi, e possono nominare identità diverse.

Una directory di proprietà di root con una modalità restrittiva è perfettamente visibile a un demone che ha già rinunciato ai privilegi, e comunque non scrivibile da lui. L’errore viene allora letto come un problema di permessi anche se il percorso esiste esattamente dove te lo aspettavi. Confronta il proprietario della directory con l’identità segnalata dall’hook. Quando differiscono, la modalità non è mai stata la questione.

Controlla l’identità con cui l’hook viene realmente eseguito prima di cambiare la proprietà. Cambiare l’utente di esecuzione del servizio per riparare una directory può alterare l’accesso ai dispositivi e i privilegi di rete altrove, il che è un prezzo alto per un problema piccolo.

Verifica l’intera consegna

Conferma quattro cose insieme: l’hook scrive sotto la sua identità reale, il lettore previsto può consumare il file, gli utenti non correlati non possono, e fermare l’unità ripulisce come progettato. Che un file compaia nella directory temporanea condivisa dell’host non è un requisito, ed è di solito il segno che lo scambio non ha mai avuto un percorso proprio. Prova il lettore dopo un riavvio, non solo durante la prima esecuzione. Il comportamento di pulizia fa parte del progetto, quindi osservalo invece di darlo per scontato.

Lo stato persistente appartiene a un luogo con una durata di vita corrispondente, poiché una directory di runtime è destinata a sparire. Scegli la posizione in base alla durata di vita e non alla comodità. Quell’abitudine evita la prossima versione di questa stessa indagine.