SSHFS-mounts horen bij de gebruiker, niet bij de VPN-hook

De aanname is makkelijk over te nemen en moeilijk op te merken: een VPN-verbindingshook draait als root, dus de mount die hij start zou ook als root geregeld moeten worden. Die redenering levert een teambibliotheek op die de desktopgebruiker niet kan openen, een mount die verdwijnt wanneer de triggerservice herstart, en een authenticatieprompt in een context waar niemand hem kan beantwoorden. De hook en de mount zijn twee verschillende taken, en slechts één ervan heeft rechten nodig.

De mythe: netwerkrechten betekenen mountrechten

Een interface omhoog brengen en je authenticeren bij een fileserver zijn onverwante vaardigheden, en ze horen meestal bij verschillende accounts. De VPN-component heeft genoeg rechten nodig om routes en interfaces te wijzigen. Het fileserveraccount heeft een sleutel of wachtwoord, een beslissing over de hostsleutel en een thuismap nodig om in te mounten. De inloggegevens van de tweede taak aan de eerste identiteit geven is hoe een netwerkdienst uiteindelijk de sleutel van een gebruiker vasthoudt.

Op een laptop met één gebruiker kunnen dat hetzelfde account zijn, en die toevalligheid is geen ontwerp.

Zodra een bevoorrechte hook de mount uitvoert, gaan drie dingen stil mis. De mount is eigendom van root, de agent van de gebruiker ontbreekt in die omgeving, en fouten verschijnen in het log van de netwerkdienst in plaats van in de sessie die het aangaat. Niets daarvan wordt gerepareerd door opties aan het mountcommando toe te voegen. Het wordt gerepareerd door de taak aan de sessie te geven die de identiteit bezit.

Waarom de mount bij de ingelogde gebruiker hoort

Een SSHFS-mount is een FUSE-mount die eigendom is van het proces dat hem heeft gemaakt, en toegang volgt dat eigendom in plaats van de modus van de bovenliggende map. De referentie raadt een gewone gebruiker aan met een mountpunt dat die gebruiker bezit, en dat is precies waarom een mount die door een root-proces is gemaakt voor alle anderen onhandig is. Een rechtenwijziging op het mountpunt repareert het niet, want het obstakel is de eigenaar van de mount zelf.

Begin met een handmatige basislijn binnen de gebruikerssessie: een bestaand leeg mountpunt onder de thuismap, een geautoriseerd account op de server en een hostsleutel die al via uw goedgekeurde proces is geverifieerd. Mount hem één keer met de hand en gebruik hem, want dat bewijst dat het identiteitspad werkt voordat er enige automatisering bestaat. Noteer wat het commando nodig had: de accountnaam, het exportpad en de privé-hostnaam. Bewaar precies die context voor de geautomatiseerde versie, want een werkende handmatige mount is de specificatie die de trigger moet reproduceren.

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

Behandel elke naam en elk pad in die regel als plaatsaanduiding, inclusief het account en de export. Een wachtwoord van een VPN-account is niet automatisch de inloggegevens van het opslagaccount.

Wat de trigger de sessie moet vragen te doen

De ondersteunde regeling is een verzoek van de netwerkgebeurtenis aan de sessie van de gebruiker, geen geleende inloggegevens. Beperk de trigger tot de verbinding die u bedoelt, op naam of UUID, in plaats van tot elke interface die toevallig tun0 heet. Die ene wijziging voorkomt dat een tweede profiel, een testtunnel of de debugsessie van een collega een mount start.

De actie aan de sessiekant moet de bedoelde bestaande mount zoeken en daarna één begrensde poging doen.

Probeer niet bij elke peiling opnieuw en blijf niet om inloggegevens vragen terwijl de server onbereikbaar is, want beide veranderen een tijdelijke storing in een accountblokkade. Een onbeheerde dienst is een apart ontwerp met eigen goedgekeurde inloggegevens en eigen hostverificatie in zijn eigen uitvoeringscontext, en kan er niet op rekenen dat iemand een grafische agent heeft ontgrendeld. Bepaal welke van de twee u bouwt voordat u kiest waar de code woont. De meeste verwarring hier komt van het ene bouwen en het andere verwachten.

Verbreken is een bestandssysteemgebeurtenis, geen hookgebeurtenis

Een geplande verbreking moet bestandsbewerkingen afronden en ontkoppelen vanuit de sessie van de mountende gebruiker met het ondersteunde commando voor dat bestandssysteemtype. Een loskoppeling forceren zodat een hook snel terugkeert, is hoe toepassingen hun werkmap verliezen en gebruikers hun vertrouwen in de automatisering. Een bezette mount heeft een beslissing op toepassingsniveau nodig, zoals het bestand sluiten of het schrijven stoppen, niet een sterker signaal. De exitstatus van de hook is niet wat wordt geoptimaliseerd.

fusermount3 -u "$HOME/mnt/team"

Onverwacht verlies is een ander geval, en SSHFS documenteert dat een onderbroken bewerking kan blokkeren terwijl het transport opnieuw verbindt.

De herverbindingsoptie herstelt het transport, en bestanden die vóór die herverbinding zijn geopend kunnen nog steeds fouten teruggeven en moeten opnieuw worden geopend. Een VPN die terugkomt bewijst niets over eerdere handles of niet-opgeslagen werk. Kies het gedrag dat u bij een storing wilt — pauzeren, een fout tonen of bewust opnieuw mounten — en test het met wegwerpbestanden voordat iets ervan afhangt.