PrivateTmp: o hook escribiu o ficheiro, pero a onde foi?

Os hooks informan de éxito, e a mesma ruta segue parecendo baleira desde unha shell. Ambas afirmacións poden ser certas á vez, porque un servizo de systemd pode vivir no seu propio espazo de nomes de montaxe cun directorio temporal privado. Unha vez entendido iso, a pregunta interesante é se a escritura chegou a funcionar.

Dous directorios temporais, unha soa ruta

O axuste de illamento dá á unidade unha visión privada dos directorios temporais en lugar de facelos de só lectura. Os procesos fóra da unidade non poden ver o que escribe alí, e todo o que deixa atrás descártase cando a unidade se detén. Por tanto, unha ruta impresa polo hook e unha ruta comprobada desde unha shell poden referirse a obxectos distintos co mesmo nome.

É un problema de visibilidade, e parece un problema de perda de datos. Non se borrou nada, porque o ficheiro simplemente está nun espazo de nomes do que a shell non forma parte. O mesmo comando compórtase de forma distinta cando se executa dentro da unidade, e esa é a observación que adoita resolver a discusión. Le os axustes da unidade antes de concluír nada sobre a escritura.

Separa o invisible do non escribible

Unha escritura correcta e unha apertura fallida producen probas distintas, e esa distinción decide a reparación. Se o hook di que o ficheiro se creou pero un lector externo non o atopa, tes unha cuestión de espazo de nomes. Se o hook informa dun erro de permisos ou dunha apertura fallida, o ficheiro nunca se escribiu e ningún cambio de espazo de nomes axudará.

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

A ruta da raíz do proceso expón a propia visión do sistema de ficheiros do servizo, suxeita ás comprobacións de permisos sobre ese proceso mentres segue en execución. Le o diario da unidade na mesma sesión, porque un erro de escritura e un ficheiro ausente confúndense facilmente cando alguén xa decidiu a causa.

Dálle aos datos compartidos unha localización explícita

Os datos que só necesita o servizo pertencen ao seu directorio temporal privado. Os datos que outro proceso debe ler necesitan unha ruta definida para ambos, cun propietario, un modo e unha caducidade declarados. Decide cal dos dous casos tes antes de editar a unidade. A maioría destes incidentes veñen de tratar un ficheiro privado como se fose compartido.

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

Un directorio de execución coloca o cartafol baixo a área de execución do sistema, créao para o usuario e o grupo configurados da unidade e elimínao cando a unidade se detén. Engádeo mediante un drop-in para que a unidade do paquete quede intacta, despois recarga o xestor e reinicia esa instancia, aceptando que os seus clientes se reconectarán.

Conserva calquera directorio de execución que a unidade instalada xa requira. Substituír a lista en lugar de engadirlle cousas é unha forma habitual de romper unha función non relacionada que ninguén conecta co cambio.

Dúas capas de privilexios poden non coincidir

O xestor de servizos crea o directorio para o usuario configurado da unidade, mentres que o daemon VPN pode baixar por separado á súa propia conta antes de executar un hook de conexión. Son capas distintas, e poden nomear identidades distintas.

Un directorio propiedade de root cun modo restritivo é perfectamente visible para un daemon que xa renunciou aos privilexios, e aínda así non pode escribir nel. O erro lese entón como un problema de permisos aínda que a ruta exista exactamente onde esperabas. Compara o propietario do directorio coa identidade que informa o hook. Cando difiren, o modo nunca foi a cuestión.

Comproba a identidade coa que se executa realmente o hook antes de cambiar a propiedade. Cambiar o usuario de execución do servizo para arranxar un directorio pode alterar o acceso aos dispositivos e os privilexios de rede noutros lugares, o que é un prezo alto para un problema pequeno.

Verifica toda a entrega

Confirma catro cousas á vez: o hook escribe baixo a súa identidade real, o lector previsto pode consumir o ficheiro, os usuarios non relacionados non poden, e deter a unidade limpa segundo o deseño. Que apareza un ficheiro no directorio temporal compartido do host non é un requisito, e adoita ser sinal de que o intercambio nunca obtivo a súa propia ruta. Proba o lector despois dun reinicio, non só durante a primeira execución. O comportamento de limpeza forma parte do deseño, así que obsérvao en lugar de supoñelo.

O estado persistente pertence a un lugar cunha vida útil equivalente, xa que un directorio de execución está feito para desaparecer. Escolle a localización pola vida útil e non pola comodidade. Ese hábito evita a próxima versión desta mesma investigación.