As montagens SSHFS pertencem ao utilizador, não ao gancho da VPN

A suposição é fácil de absorver e difícil de notar: um gancho de ligação VPN é executado como root, pelo que a montagem que inicia também deveria ser organizada como root. Esse raciocínio produz um diretório de equipa que o utilizador do ambiente de trabalho não consegue abrir, uma montagem que desaparece quando o serviço de gatilho reinicia e um pedido de autenticação num contexto em que ninguém o pode responder. O gancho e a montagem são dois trabalhos diferentes, e apenas um deles precisa de privilégios.

O mito: privilégio de rede implica privilégio de montagem

Levantar uma interface e autenticar num servidor de ficheiros são capacidades não relacionadas, e normalmente pertencem a contas diferentes. O componente VPN precisa de privilégios suficientes para alterar rotas e interfaces. A conta do servidor de ficheiros precisa de uma chave ou palavra-passe, de uma decisão sobre a chave do anfitrião e de um diretório pessoal onde montar. Entregar as credenciais do segundo trabalho à primeira identidade é como um serviço de rede acaba por guardar a chave de um utilizador.

Num portátil de um só utilizador podem ser a mesma conta, e essa coincidência não é um desenho.

Assim que um gancho privilegiado faz a montagem, três coisas correm mal em silêncio. A montagem pertence ao root, o agente do utilizador está ausente desse ambiente, e as falhas aparecem no registo do serviço de rede em vez de na sessão que se importa. Nada disso é reparado acrescentando opções ao comando de montagem. É reparado dando o trabalho à sessão que possui a identidade.

Porque é que a montagem pertence ao utilizador com sessão iniciada

Uma montagem SSHFS é uma montagem FUSE pertencente ao processo que a criou, e o acesso segue essa propriedade em vez do modo do diretório pai. A referência recomenda um utilizador normal com um ponto de montagem que esse utilizador possua, e é exatamente por isso que uma montagem criada por um processo root é incómoda para todos os outros. Uma alteração de permissões no ponto de montagem não a repara, porque o obstáculo é o próprio dono da montagem.

Comece com uma base manual dentro da sessão do utilizador: um ponto de montagem vazio existente sob o diretório pessoal, uma conta autorizada no servidor e uma chave de anfitrião já verificada pelo seu processo aprovado. Monte-o à mão uma vez e utilize-o, porque isso prova que o caminho da identidade funciona antes de existir qualquer automatização. Anote o que o comando precisou: o nome da conta, o caminho de exportação e o nome de anfitrião privado. Mantenha esse contexto exato para a versão automatizada, já que uma montagem manual funcional é a especificação que o gatilho tem de reproduzir.

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

Trate cada nome e caminho dessa linha como um marcador de posição, incluindo a conta e a exportação. A palavra-passe de uma conta VPN não é automaticamente a credencial da conta de armazenamento.

O que o gatilho deve pedir à sessão

A disposição suportada é um pedido do evento de rede para a sessão do utilizador, não uma credencial emprestada. Limite o gatilho à ligação que pretende, por nome ou UUID, em vez de a qualquer interface que se chame tun0 por acaso. Essa única alteração impede um segundo perfil, um túnel de teste ou a sessão de depuração de um colega de iniciar uma montagem.

A ação do lado da sessão deve procurar a montagem existente pretendida e depois fazer uma única tentativa limitada.

Não tente novamente em cada sondagem e não continue a pedir uma credencial enquanto o servidor estiver inacessível, porque ambas transformam uma interrupção transitória num bloqueio de conta. Um serviço sem supervisão é um desenho separado, com credenciais aprovadas próprias e a sua própria verificação de anfitrião no seu próprio contexto de execução, e não pode contar com alguém ter desbloqueado um agente gráfico. Decida qual dos dois está a construir antes de escolher onde vive o código. A maior parte da confusão aqui vem de construir um e esperar o outro.

A desconexão é um evento do sistema de ficheiros, não um evento do gancho

Uma desconexão planeada deve concluir as operações de ficheiros e desmontar a partir da sessão do utilizador que monta com o comando suportado para esse tipo de sistema de ficheiros. Forçar um desacoplamento para que um gancho volte depressa é como as aplicações perdem o diretório de trabalho e os utilizadores perdem a confiança na automatização. Uma montagem ocupada precisa de uma decisão ao nível da aplicação, como fechar o ficheiro ou parar a escrita, não de um sinal mais forte. O estado de saída do gancho não é o que se otimiza.

fusermount3 -u "$HOME/mnt/team"

A perda inesperada é um caso diferente, e o SSHFS documenta que uma operação interrompida pode bloquear enquanto o transporte se reconecta.

A opção de reconexão restaura o transporte, e os ficheiros abertos antes dessa reconexão ainda podem devolver erros e precisar de reabertura. Uma VPN que regressa não prova nada sobre identificadores anteriores nem sobre trabalho não guardado. Escolha o comportamento que quer numa interrupção — pausar, mostrar um erro ou remontar de propósito — e teste-o com ficheiros descartáveis antes de algo depender dele.