SSHFS-monteringar tillhör användaren, inte VPN-kroken

Antagandet är lätt att ta till sig och svårt att lägga märke till: en VPN-anslutningskrok körs som root, så monteringen den startar bör också ordnas som root. Det resonemanget ger en teamkatalog som skrivbordsanvändaren inte kan öppna, en montering som försvinner när utlösartjänsten startar om, och en autentiseringsfråga i en kontext där ingen kan svara på den. Kroken och monteringen är två olika jobb, och bara ett av dem behöver behörigheter.

Myten: nätverksbehörigheter betyder monteringsbehörigheter

Att höja ett gränssnitt och autentisera mot en filserver är oberoende förmågor, och de tillhör vanligtvis olika konton. VPN-komponenten behöver tillräckliga behörigheter för att ändra rutter och gränssnitt. Filserverkontot behöver en nyckel eller ett lösenord, ett beslut om värdnyckeln och en hemkatalog att montera i. Att ge det andra jobbets inloggningsuppgifter till den första identiteten är hur en nätverkstjänst hamnar med en användares nyckel.

På en laptop med en enda användare kan det vara samma konto, och den slumpen är inte en design.

När en privilegierad krok väl gör monteringen går tre saker tyst fel. Monteringen ägs av root, användarens agent saknas i den miljön, och fel syns i nätverkstjänstens logg i stället för i sessionen som bryr sig. Inget av det repareras genom att lägga till alternativ i monteringskommandot. Det repareras genom att ge jobbet till sessionen som äger identiteten.

Varför monteringen tillhör den inloggade användaren

En SSHFS-montering är en FUSE-montering som ägs av processen som skapade den, och åtkomst följer det ägandet i stället för den överordnade katalogens läge. Referensen rekommenderar en vanlig användare med en monteringspunkt som användaren äger, och det är just därför en montering skapad av en root-process är besvärlig för alla andra. En behörighetsändring på monteringspunkten reparerar det inte, eftersom hindret är monteringens egen ägare.

Börja med en manuell baslinje inne i användarsessionen: en befintlig tom monteringspunkt under hemkatalogen, ett auktoriserat konto på servern och en värdnyckel som redan verifierats genom din godkända process. Montera den manuellt en gång och använd den, eftersom det bevisar att identitetsvägen fungerar innan någon automatisering finns. Notera vad kommandot behövde: kontonamnet, exportvägen och det privata värdnamnet. Behåll exakt den kontexten för den automatiserade versionen, eftersom en fungerande manuell montering är specifikationen som utlösaren måste återskapa.

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

Behandla varje namn och varje sökväg på den raden som en platshållare, inklusive kontot och exporten. Ett VPN-kontolösenord är inte automatiskt lagringskontots inloggningsuppgift.

Vad utlösaren bör be sessionen om att göra

Den stödda ordningen är en begäran från nätverkshändelsen till användarens session, inte lånade inloggningsuppgifter. Begränsa utlösaren till den anslutning du menar, med namn eller UUID, i stället för till vilket gränssnitt som helst som råkar heta tun0. Den enda ändringen hindrar en andra profil, en testtunnel eller en kollegas felsökningssession från att starta en montering.

Åtgärden på sessionssidan bör leta efter den avsedda befintliga monteringen och sedan göra ett enda begränsat försök.

Försök inte igen vid varje avfrågning och fortsätt inte be om inloggningsuppgifter medan servern är oåtkomlig, eftersom båda förvandlar ett tillfälligt avbrott till en kontolåsning. En oövervakad tjänst är en separat design med egna godkända inloggningsuppgifter och egen värdverifiering i sin egen körningskontext, och den kan inte räkna med att någon har låst upp en grafisk agent. Bestäm vilken av de två du bygger innan du väljer var koden bor. Det mesta av förvirringen här kommer av att bygga den ena och förvänta sig den andra.

Frånkoppling är en filsystemshändelse, inte en krokhändelse

En planerad frånkoppling bör slutföra filoperationer och avmontera från den monterande användarens session med det stödda kommandot för den filsystemstypen. Att tvinga fram en avkoppling för att en krok ska återvända snabbt är hur program förlorar sin arbetskatalog och användare förlorar förtroendet för automatiseringen. En upptagen montering behöver ett beslut på programnivå, som att stänga filen eller stoppa skrivningen, inte en starkare signal. Krokens utgångsstatus är inte det som optimeras.

fusermount3 -u "$HOME/mnt/team"

Oväntad förlust är ett annat fall, och SSHFS dokumenterar att en avbruten operation kan blockera medan transporten återansluter.

Återanslutningsalternativet återställer transporten, och filer som öppnades före den återanslutningen kan fortfarande returnera fel och behöva öppnas igen. En VPN som kommer tillbaka bevisar ingenting om tidigare handtag eller osparat arbete. Välj det beteende du vill ha vid ett avbrott — pausa, visa ett fel eller avsiktligt montera om — och testa det med engångsfiler innan något beror på det.