I mount SSHFS appartengono all’utente, non all’hook della VPN

L’ipotesi è facile da assorbire e difficile da notare: un hook di connessione VPN viene eseguito come root, quindi anche il mount che avvia dovrebbe essere organizzato come root. Quel ragionamento produce una directory di team che l’utente del desktop non riesce ad aprire, un mount che scompare quando il servizio trigger viene riavviato e una richiesta di autenticazione in un contesto in cui nessuno può rispondere. L’hook e il mount sono due lavori diversi, e solo uno dei due ha bisogno di privilegi.

Il mito: il privilegio di rete implica il privilegio di mount

Alzare un’interfaccia e autenticarsi su un file server sono capacità non correlate, e di solito appartengono ad account diversi. Il componente VPN ha bisogno di privilegi sufficienti per cambiare rotte e interfacce. L’account del file server ha bisogno di una chiave o di una password, di una decisione sulla chiave host e di una directory home in cui montare. Consegnare le credenziali del secondo lavoro alla prima identità è il modo in cui un servizio di rete finisce per custodire la chiave di un utente.

Su un portatile a utente singolo possono essere lo stesso account, e quella coincidenza non è un progetto.

Una volta che un hook privilegiato esegue il mount, tre cose vanno storte in silenzio. Il mount è di proprietà di root, l’agente dell’utente è assente da quell’ambiente e gli errori emergono nel log del servizio di rete anziché nella sessione a cui importa. Niente di tutto ciò si ripara aggiungendo opzioni al comando di mount. Si ripara affidando il lavoro alla sessione che possiede l’identità.

Perché il mount appartiene all’utente che ha effettuato l’accesso

Un mount SSHFS è un mount FUSE di proprietà del processo che lo ha creato, e l’accesso segue quella proprietà invece del modo della directory padre. Il riferimento raccomanda un utente normale con un punto di mount che quell’utente possiede, ed è esattamente per questo che un mount creato da un processo root è scomodo per tutti gli altri. Un cambio di permessi sul punto di mount non lo ripara, perché l’ostacolo è il proprietario del mount stesso.

Partite da una base manuale dentro la sessione dell’utente: un punto di mount vuoto esistente sotto la directory home, un account autorizzato sul server e una chiave host già verificata tramite la vostra procedura approvata. Montatelo a mano una volta e usatelo, perché questo dimostra che il percorso dell’identità funziona prima che esista qualsiasi automazione. Annotate ciò che serviva al comando: il nome dell’account, il percorso di esportazione e il nome host privato. Conservate quel contesto esatto per la versione automatizzata, perché un mount manuale funzionante è la specifica che il trigger deve riprodurre.

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

Trattate ogni nome e percorso di quella riga come segnaposto, incluso l’account e l’esportazione. La password di un account VPN non è automaticamente la credenziale dell’account di archiviazione.

Cosa deve chiedere il trigger alla sessione

La disposizione supportata è una richiesta dall’evento di rete alla sessione dell’utente, non una credenziale presa in prestito. Limitate il trigger alla connessione che intendete, per nome o UUID, invece che a qualsiasi interfaccia che si chiami per caso tun0. Quell’unico cambiamento impedisce a un secondo profilo, a un tunnel di prova o alla sessione di debug di un collega di avviare un mount.

L’azione lato sessione dovrebbe cercare il mount esistente previsto e poi fare un solo tentativo limitato.

Non riprovate a ogni interrogazione e non continuate a chiedere una credenziale mentre il server non è raggiungibile, perché entrambe le cose trasformano un’interruzione temporanea in un blocco dell’account. Un servizio senza supervisione è un progetto separato, con le proprie credenziali approvate e la propria verifica dell’host nel proprio contesto di esecuzione, e non può contare che qualcuno abbia sbloccato un agente grafico. Decidete quale dei due state costruendo prima di scegliere dove vive il codice. La maggior parte della confusione qui nasce dal costruirne uno e aspettarsi l’altro.

La disconnessione è un evento del file system, non un evento dell’hook

Una disconnessione pianificata dovrebbe completare le operazioni sui file e smontare dalla sessione dell’utente che monta con il comando supportato per quel tipo di file system. Forzare un distacco perché un hook torni in fretta è il modo in cui le applicazioni perdono la directory di lavoro e gli utenti perdono fiducia nell’automazione. Un mount occupato ha bisogno di una decisione a livello applicativo, come chiudere il file o fermare la scrittura, non di un segnale più forte. Lo stato di uscita dell’hook non è ciò che viene ottimizzato.

fusermount3 -u "$HOME/mnt/team"

La perdita imprevista è un caso diverso, e SSHFS documenta che un’operazione interrotta può bloccarsi mentre il trasporto si riconnette.

L’opzione di riconnessione ripristina il trasporto, e i file aperti prima di quella riconnessione possono ancora restituire errori e richiedere riapertura. Una VPN che ritorna non dimostra nulla sui descrittori precedenti né sul lavoro non salvato. Scegliete il comportamento che volete in caso di interruzione — sospensione, visualizzazione di un errore o rimontaggio deliberato — e provatelo con file usa e getta prima che qualcosa dipenda da esso.