Els muntatges SSHFS pertanyen a l’usuari, no al ganxo de la VPN

La suposició és fàcil d’absorbir i difícil de notar: un ganxo de connexió de la VPN s’executa com a root, així que el muntatge que inicia també s’hauria d’organitzar com a root. Aquest raonament produeix un directori d’equip que l’usuari d’escriptori no pot obrir, un muntatge que desapareix quan el servei disparador es reinicia i una sol·licitud d’autenticació en un context on ningú no la pot respondre. El ganxo i el muntatge són dues feines diferents, i només una d’elles necessita privilegis.

El mite: el privilegi de xarxa implica el privilegi de muntatge

Aixecar una interfície i autenticar-se en un servidor de fitxers són capacitats no relacionades, i normalment pertanyen a comptes diferents. El component de la VPN necessita prou privilegis per canviar rutes i interfícies. El compte del servidor de fitxers necessita una clau o una contrasenya, una decisió sobre la clau d’amfitrió i un directori personal on muntar. Lliurar les credencials de la segona feina a la primera identitat és com un servei de xarxa acaba guardant la clau d’un usuari.

En un portàtil d’un sol usuari poden ser el mateix compte, i aquesta coincidència no és un disseny.

Un cop un ganxo privilegiat fa el muntatge, tres coses fallen en silenci. El muntatge és propietat de root, l’agent de l’usuari no és en aquell entorn i les fallades apareixen al registre del servei de xarxa en lloc de la sessió que hi té interès. Cap d’aquestes coses es repara afegint opcions a l’ordre de muntatge. Es reparen donant la feina a la sessió que posseeix la identitat.

Per què el muntatge pertany a l’usuari que ha iniciat la sessió

Un muntatge SSHFS és un muntatge FUSE propietat del procés que l’ha creat, i l’accés segueix aquesta propietat i no el mode del directori pare. La referència recomana un usuari normal amb un punt de muntatge que aquest usuari posseeixi, i és exactament per això que un muntatge creat per un procés root resulta incòmode per a tothom. Un canvi de permisos al punt de muntatge no ho repara, perquè l’obstacle és el propietari del mateix muntatge.

Comenceu amb una línia de base manual dins de la sessió de l’usuari: un punt de muntatge buit existent sota el directori personal, un compte autoritzat al servidor i una clau d’amfitrió ja verificada pel vostre procés aprovat. Monteu-lo a mà un cop i feu-lo servir, perquè això demostra que el camí d’identitat funciona abans que existeixi cap automatització. Anoteu què necessitava l’ordre: el nom del compte, el camí d’exportació i el nom d’amfitrió privat. Mantingueu aquest context exacte per a la versió automatitzada, ja que un muntatge manual que funciona és l’especificació que el disparador ha de reproduir.

sshfs [email protected]:/exports/team "$HOME/mnt/team"

Tracteu cada nom i camí d’aquella línia com un marcador de posició, inclòs el compte i l’exportació. La contrasenya d’un compte de VPN no és automàticament la credencial del compte d’emmagatzematge.

Què ha de demanar el disparador a la sessió

La disposició suportada és una petició de l’esdeveniment de xarxa a la sessió de l’usuari, no una credencial manllevada. Limiteu el disparador a la connexió que voleu, per nom o UUID, i no a qualsevol interfície que es digui tun0 per casualitat. Aquest sol canvi impedeix que un segon perfil, un túnel de prova o una sessió de depuració d’un company iniciïn un muntatge.

L’acció del costat de la sessió hauria de buscar el muntatge existent previst i fer després un únic intent limitat.

No torneu a intentar-ho a cada sondeig i no continueu demanant una credencial mentre el servidor no és accessible, perquè totes dues coses converteixen una interrupció transitòria en un bloqueig del compte. Un servei sense supervisió és un disseny separat, amb la seva pròpia credencial aprovada i la seva pròpia disposició de verificació d’amfitrió en el seu propi context d’execució, i no pot dependre que algú hagi desbloquejat un agent gràfic. Decidiu quin dels dos esteu construint abans de triar on viu el codi. La major part de la confusió aquí ve de construir-ne un i esperar l’altre.

La desconnexió és un esdeveniment del sistema de fitxers, no un esdeveniment del ganxo

Una desconnexió planificada hauria d’acabar les operacions de fitxers i desmuntar des de la sessió de l’usuari que munta amb l’ordre suportada per a aquell tipus de sistema de fitxers. Forçar un desacoblament perquè un ganxo torni de pressa és com les aplicacions perden el directori de treball i els usuaris perden la confiança en l’automatització. Un muntatge ocupat necessita una decisió a nivell d’aplicació, com ara tancar el fitxer o aturar l’escriptura, no un senyal més fort. L’estat de sortida del ganxo no és el que s’optimitza.

fusermount3 -u "$HOME/mnt/team"

La pèrdua inesperada és un cas diferent, i SSHFS documenta que una operació interrompuda pot bloquejar-se mentre el transport es reconnecta.

L’opció de reconnexió restaura el transport, i els fitxers oberts abans d’aquesta reconnexió encara poden retornar errors i necessitar tornar-se a obrir. Una VPN que torna no demostra res sobre els identificadors anteriors ni sobre la feina no desada. Trieu el comportament que voleu en una interrupció —pausar, mostrar un error o tornar a muntar a propòsit— i proveu-lo amb fitxers d’un sol ús abans que res no en depengui.