As montaxes SSHFS pertencen ao usuario, non ao gancho da VPN

A suposición é fácil de absorber e difícil de notar: un gancho de conexión da VPN execútase como root, así que a montaxe que inicia tamén debería organizarse como root. Ese razoamento produce un directorio de equipo que o usuario de escritorio non pode abrir, unha montaxe que desaparece cando o servizo disparador se reinicia e unha solicitude de autenticación nun contexto onde ninguén pode respondela. O gancho e a montaxe son dous traballos distintos, e só un deles necesita privilexios.

O mito: o privilexio de rede implica o privilexio de montaxe

Levantar unha interface e autenticarse nun servidor de ficheiros son capacidades non relacionadas, e normalmente pertencen a contas diferentes. O compoñente da VPN necesita privilexios suficientes para cambiar rutas e interfaces. A conta do servidor de ficheiros necesita unha chave ou un contrasinal, unha decisión sobre a chave de host e un directorio persoal onde montar. Entregar as credenciais do segundo traballo á primeira identidade é como un servizo de rede acaba gardando a chave dun usuario.

Nun portátil dun só usuario poden ser a mesma conta, e esa coincidencia non é un deseño.

Unha vez que un gancho privilexiado fai a montaxe, tres cousas fallan en silencio. A montaxe é propiedade de root, o axente do usuario non está nese contorno e os fallos aparecen no rexistro do servizo de rede en lugar de na sesión á que lle importan. Nada diso se repara engadindo opcións á orde de montaxe. Repárase dándolle o traballo á sesión que posúe a identidade.

Por que a montaxe pertence ao usuario que iniciou sesión

Unha montaxe SSHFS é unha montaxe FUSE propiedade do proceso que a creou, e o acceso segue esa propiedade en lugar do modo do directorio pai. A referencia recomenda un usuario normal cun punto de montaxe que ese usuario posúa, e é exactamente por iso que unha montaxe creada por un proceso root resulta incómoda para todos os demais. Un cambio de permisos no punto de montaxe non o repara, porque o obstáculo é o propio dono da montaxe.

Comece cunha liña base manual dentro da sesión do usuario: un punto de montaxe baleiro existente baixo o directorio persoal, unha conta autorizada no servidor e unha chave de host xa verificada mediante o seu proceso aprobado. Mónteo a man unha vez e úseo, porque iso demostra que a ruta de identidade funciona antes de que exista calquera automatización. Anote o que necesitou a orde: o nome da conta, a ruta de exportación e o nome de host privado. Conserve ese contexto exacto para a versión automatizada, xa que unha montaxe manual que funciona é a especificación que o disparador debe reproducir.

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

Trate cada nome e ruta desa liña como un marcador de posición, incluídos a conta e a exportación. O contrasinal dunha conta de VPN non é automaticamente a credencial da conta de almacenamento.

Que debe pedir o disparador á sesión

A disposición admitida é unha petición do evento de rede á sesión do usuario, non unha credencial prestada. Limite o disparador á conexión que quere, por nome ou UUID, e non a calquera interface que se chame tun0 por casualidade. Ese único cambio impide que un segundo perfil, un túnel de proba ou a sesión de depuración dun compañeiro inicien unha montaxe.

A acción do lado da sesión debería buscar a montaxe existente prevista e logo facer un único intento acoutado.

Non reintente en cada sondaxe e non siga pedindo unha credencial mentres o servidor non sexa accesible, porque ambas as cousas converten unha interrupción transitoria nun bloqueo da conta. Un servizo sen supervisión é un deseño aparte, coa súa propia credencial aprobada e a súa propia disposición de verificación de host no seu propio contexto de execución, e non pode depender de que alguén desbloquease un axente gráfico. Decida cal dos dous está construíndo antes de elixir onde vive o código. A maior parte da confusión aquí vén de construír un e esperar o outro.

A desconexión é un evento do sistema de ficheiros, non un evento do gancho

Unha desconexión planificada debería rematar as operacións de ficheiros e desmontar desde a sesión do usuario que monta coa orde admitida para ese tipo de sistema de ficheiros. Forzar un desacoplamento para que un gancho volva rápido é como as aplicacións perden o seu directorio de traballo e os usuarios perden a confianza na automatización. Unha montaxe ocupada necesita unha decisión a nivel de aplicación, como pechar o ficheiro ou deter a escritura, non un sinal máis forte. O estado de saída do gancho non é o que se optimiza.

fusermount3 -u "$HOME/mnt/team"

A perda inesperada é un caso distinto, e SSHFS documenta que unha operación interrompida pode bloquearse mentres o transporte se reconecta.

A opción de reconexión restaura o transporte, e os ficheiros abertos antes desa reconexión aínda poden devolver erros e necesitar reapertura. Unha VPN que volve non demostra nada sobre identificadores anteriores nin sobre traballo sen gardar. Escolla o comportamento que quere ante unha interrupción —pausar, amosar un erro ou volver montar a propósito— e probéxeo con ficheiros de usar e tirar antes de que algo dependa del.