SSHFS-mounts tilhører brugeren, ikke VPN-krogen

Antagelsen er let at overtage og svær at bemærke: en VPN-forbindelseskrog kører som root, så det mount, den starter, bør også indrettes som root. Den ræsonnering giver en teammappe, som skrivebordsbrugeren ikke kan åbne, et mount der forsvinder, når den udløsende tjeneste genstarter, og en godkendelsesdialog i en kontekst, hvor ingen kan svare på den. Krogen og mountet er to forskellige opgaver, og kun én af dem kræver rettigheder.

Myten: netværksrettigheder betyder mount-rettigheder

At hæve en grænseflade og godkende over for en filserver er uafhængige evner, og de hører normalt til forskellige konti. VPN-komponenten har brug for tilstrækkelige rettigheder til at ændre ruter og grænseflader. Filserverkontoen har brug for en nøgle eller en adgangskode, en beslutning om værtsnøglen og en hjemmemappe at montere i. At give den anden opgaves legitimationsoplysninger til den første identitet er, hvordan en netværkstjeneste ender med at holde på en brugers nøgle.

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

Når først en privilegeret krog udfører mountet, går tre ting stille galt. Mountet ejes af root, brugerens agent mangler i det miljø, og fejl viser sig i netværkstjenestens log i stedet for i den session, der er berørt. Ingen af dem repareres ved at tilføje valgmuligheder til mount-kommandoen. De repareres ved at give opgaven til den session, der ejer identiteten.

Hvorfor mountet tilhører den indloggede bruger

Et SSHFS-mount er et FUSE-mount, der ejes af den proces, som oprettede det, og adgang følger det ejerskab frem for den overordnede mappes tilstand. Referencen anbefaler en almindelig bruger med et monteringspunkt, som brugeren ejer, og det er netop derfor, at et mount oprettet af en root-proces er akavet for alle andre. En ændring af tilladelserne på monteringspunktet reparerer det ikke, fordi hindringen er mountets egen ejer.

Start med en manuel baseline inde i brugersessionen: et eksisterende tomt monteringspunkt under hjemmemappen, en autoriseret konto på serveren og en værtsnøgle, der allerede er verificeret gennem din godkendte proces. Montér det manuelt én gang og brug det, fordi det beviser, at identitetsvejen virker, før der findes nogen automatisering. Notér, hvad kommandoen havde brug for: kontonavnet, eksportstien og det private værtsnavn. Behold præcis den kontekst til den automatiserede version, da et fungerende manuelt mount er den specifikation, som udløseren skal genskabe.

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

Behandl hvert navn og hver sti i den linje som en pladsholder, inklusive kontoen og eksporten. En VPN-kontoadgangskode er ikke automatisk lagerkontoens legitimationsoplysning.

Hvad udløseren skal bede sessionen om at gøre

Den understøttede ordning er en anmodning fra netværkshændelsen til brugerens session, ikke en lånt legitimationsoplysning. Afgræns udløseren til den forbindelse, du mener, ved navn eller UUID, i stedet for til enhver grænseflade, der tilfældigvis hedder tun0. Den ene ændring forhindrer en anden profil, en testtunnel eller en kollegas fejlretningssession i at starte et mount.

Handlingen på sessionssiden bør lede efter det tilsigtede eksisterende mount og derefter gøre ét afgrænset forsøg.

Forsøg ikke igen ved hver afstemning, og bliv ikke ved med at spørge om legitimationsoplysninger, mens serveren er utilgængelig, fordi begge dele gør en forbigående afbrydelse til en kontolåsning. En uovervåget tjeneste er et separat design med egne godkendte legitimationsoplysninger og egen værtsbekræftelse i sin egen eksekveringskontekst, og den kan ikke regne med, at nogen har låst en grafisk agent op. Beslut, hvilken af de to du bygger, før du vælger, hvor koden bor. Det meste af forvirringen her kommer af at bygge den ene og forvente den anden.

Afbrydelse er en filsystemhændelse, ikke en kroghændelse

En planlagt afbrydelse bør afslutte filoperationer og afmontere fra den monterende brugers session med den understøttede kommando til den filsystemtype. At tvinge en afkobling for at få en krog til at vende hurtigt tilbage er, hvordan programmer mister deres arbejdsmappe, og brugere mister tilliden til automatiseringen. Et optaget mount har brug for en beslutning på programniveau, såsom at lukke filen eller stoppe skrivningen, ikke et stærkere signal. Krogens afslutningsstatus er ikke det, der optimeres.

fusermount3 -u "$HOME/mnt/team"

Uventet tab er et andet tilfælde, og SSHFS dokumenterer, at en afbrudt operation kan blokere, mens transporten genopretter forbindelsen.

Genopretningsvalget gendanner transporten, og filer åbnet før den genopretning kan stadig returnere fejl og skal åbnes igen. En VPN, der vender tilbage, beviser intet om tidligere håndtag eller ikke-gemt arbejde. Vælg den adfærd, du ønsker ved en afbrydelse — pause, visning af en fejl eller tilsigtet genmontering — og test den med engangsfiler, før noget afhænger af den.