SSHFS-monteringer tilhører brukeren, ikke VPN-kroken

Antakelsen er lett å ta til seg og vanskelig å legge merke til: en VPN-tilkoblingskrok kjører som root, så mountet den starter bør også ordnes som root. Den resonnementet gir en teammappe skrivebordsbrukeren ikke kan åpne, et mount som forsvinner når utløsertjenesten starter på nytt, og en autentiseringsforespørsel i en kontekst der ingen kan svare på den. Kroken og mountet er to forskjellige jobber, og bare én av dem trenger rettigheter.

Myten: nettverksrettigheter betyr mount-rettigheter

Å heve et grensesnitt og autentisere mot en filserver er uavhengige evner, og de tilhører vanligvis forskjellige kontoer. VPN-komponenten trenger nok rettigheter til å endre ruter og grensesnitt. Filserverkontoen trenger en nøkkel eller et passord, en beslutning om vertsnøkkelen og en hjemmekatalog å montere i. Å gi den andre jobbens legitimasjon til den første identiteten er måten en nettverkstjeneste ender med å holde på en brukers nøkkel.

På en laptop med én bruker kan det være samme konto, og den tilfeldigheten er ikke et design.

Når en privilegert krok først gjør mountet, går tre ting stille galt. Mountet eies av root, brukerens agent mangler i det miljøet, og feil vises i nettverkstjenestens logg i stedet for i sesjonen som bryr seg. Ingen av dem repareres ved å legge til valg i mount-kommandoen. De repareres ved å gi jobben til sesjonen som eier identiteten.

Hvorfor mountet tilhører den innloggede brukeren

Et SSHFS-mount er et FUSE-mount som eies av prosessen som opprettet det, og tilgang følger det eierskapet i stedet for modusen til overordnet katalog. Referansen anbefaler en vanlig bruker med et monteringspunkt som brukeren eier, og det er nettopp derfor et mount opprettet av en root-prosess er ubekvemt for alle andre. En tillatelsesendring på monteringspunktet reparerer det ikke, fordi hindringen er mountets egen eier.

Start med en manuell grunnlinje inne i brukersesjonen: et eksisterende tomt monteringspunkt under hjemmekatalogen, en autorisert konto på serveren og en vertsnøkkel som allerede er verifisert gjennom din godkjente prosess. Monter det manuelt én gang og bruk det, fordi det beviser at identitetsveien virker før noen automatisering finnes. Noter hva kommandoen trengte: kontonavnet, eksportstien og det private vertsnavnet. Behold nøyaktig den konteksten for den automatiserte versjonen, siden et fungerende manuelt mount er spesifikasjonen utløseren må gjenskape.

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

Behandle hvert navn og hver sti på den linjen som en plassholder, inkludert kontoen og eksporten. Et VPN-kontopassord er ikke automatisk legitimasjonen til lagringskontoen.

Hva utløseren bør be sesjonen om å gjøre

Den støttede ordningen er en forespørsel fra nettverkshendelsen til brukerens sesjon, ikke legitimasjon som er lånt. Begrens utløseren til tilkoblingen du mener, ved navn eller UUID, i stedet for til et hvilket som helst grensesnitt som tilfeldigvis heter tun0. Den ene endringen hindrer en annen profil, en testtunnel eller en kollegas feilsøkingssesjon i å starte et mount.

Handlingen på sesjonssiden bør lete etter det tiltenkte eksisterende mountet og deretter gjøre ett avgrenset forsøk.

Ikke prøv på nytt ved hver avstemming, og ikke fortsett å be om legitimasjon mens serveren er utilgjengelig, fordi begge gjør en forbigående avbrudd til en kontolåsing. En uovervåket tjeneste er et separat design med egne godkjente legitimasjon og egen vertsverifisering i sin egen kjørekontekst, og den kan ikke regne med at noen har låst opp en grafisk agent. Bestem hvilken av de to du bygger før du velger hvor koden bor. Det meste av forvirringen her kommer av å bygge den ene og forvente den andre.

Frakobling er en filsystemhendelse, ikke en krokhendelse

En planlagt frakobling bør fullføre filoperasjoner og avmontere fra den monterende brukerens sesjon med den støttede kommandoen for den filsystemtypen. Å tvinge en avkobling for at en krok skal komme raskt tilbake er måten programmer mister arbeidskatalogen sin og brukere mister tilliten til automatiseringen. Et opptatt mount trenger en beslutning på programnivå, som å lukke filen eller stoppe skrivingen, ikke et sterkere signal. Utløserens exitstatus er ikke det som optimaliseres.

fusermount3 -u "$HOME/mnt/team"

Uventet tap er et annet tilfelle, og SSHFS dokumenterer at en avbrutt operasjon kan blokkere mens transporten kobler til på nytt.

Gjenoppkoblingsvalget gjenoppretter transporten, og filer som ble åpnet før den gjenoppkoblingen kan fortsatt returnere feil og må åpnes på nytt. En VPN som kommer tilbake beviser ingenting om tidligere håndtak eller ulagret arbeid. Velg oppførselen du vil ha ved et avbrudd — pause, vise en feil eller bevisst montere på nytt — og test den med engangsfiler før noe avhenger av den.