Montările SSHFS aparțin utilizatorului, nu cârligului VPN

Ipoteza este ușor de asimilat și greu de observat: un cârlig de conectare VPN rulează ca root, așa că montarea pe care o pornește ar trebui organizată tot ca root. Acest raționament produce un director de echipă pe care utilizatorul desktopului nu îl poate deschide, o montare care dispare când serviciul declanșator repornește și o solicitare de autentificare într-un context în care nimeni nu poate răspunde. Cârligul și montarea sunt două lucrări diferite, iar doar una dintre ele are nevoie de privilegii.

Mitul: privilegiul de rețea implică privilegiul de montare

Ridicarea unei interfețe și autentificarea la un server de fișiere sunt capacități nelegate între ele și aparțin de obicei unor conturi diferite. Componenta VPN are nevoie de privilegii suficiente pentru a schimba rute și interfețe. Contul serverului de fișiere are nevoie de o cheie sau o parolă, de o decizie privind cheia gazdă și de un director home în care să monteze. Predarea acreditărilor celei de-a doua lucrări primei identități este modul în care un serviciu de rețea ajunge să țină cheia unui utilizator.

Pe un laptop cu un singur utilizator acestea pot fi același cont, iar coincidența nu este un design.

Odată ce un cârlig privilegiat face montarea, trei lucruri merg prost în liniște. Montarea aparține lui root, agentul utilizatorului lipsește din acel mediu, iar eșecurile apar în jurnalul serviciului de rețea, nu în sesiunea căreia îi pasă. Nimic din toate acestea nu se repară adăugând opțiuni la comanda de montare. Se repară dând lucrarea sesiunii care deține identitatea.

De ce montarea aparține utilizatorului conectat

O montare SSHFS este o montare FUSE deținută de procesul care a creat-o, iar accesul urmează acea proprietate, nu modul directorului părinte. Referința recomandă un utilizator obișnuit cu un punct de montare pe care acesta îl deține, și exact de aceea o montare creată de un proces root este incomodă pentru toți ceilalți. O schimbare de permisiuni la punctul de montare nu o repară, pentru că obstacolul este proprietarul montării înseși.

Începeți cu o linie de bază manuală în sesiunea utilizatorului: un punct de montare gol existent sub directorul home, un cont autorizat pe server și o cheie gazdă deja verificată prin procesul dumneavoastră aprobat. Montați-o manual o dată și folosiți-o, pentru că asta demonstrează că traseul identității funcționează înainte de a exista vreo automatizare. Notați de ce a avut nevoie comanda: numele contului, calea de export și numele privat al gazdei. Păstrați exact acel context pentru versiunea automatizată, deoarece o montare manuală funcțională este specificația pe care declanșatorul trebuie să o reproducă.

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

Tratați fiecare nume și cale din acea linie ca substituent, inclusiv contul și exportul. Parola unui cont VPN nu este automat acreditarea contului de stocare.

Ce ar trebui să ceară declanșatorul sesiunii

Aranjamentul acceptat este o cerere de la evenimentul de rețea către sesiunea utilizatorului, nu o acreditare împrumutată. Limitați declanșatorul la conexiunea vizată, după nume sau UUID, nu la orice interfață care se întâmplă să se numească tun0. Acea singură schimbare împiedică un al doilea profil, un tunel de test sau sesiunea de depanare a unui coleg să pornească o montare.

Acțiunea din partea sesiunii ar trebui să caute montarea existentă dorită și apoi să facă o singură încercare limitată.

Nu reîncercați la fiecare interogare și nu continuați să cereți o acreditare cât timp serverul este inaccesibil, pentru că ambele transformă o întrerupere temporară într-o blocare a contului. Un serviciu nesupravegheat este un design separat, cu propriile acreditări aprobate și propria verificare a gazdei în propriul context de execuție, și nu se poate baza pe faptul că cineva a deblocat un agent grafic. Decideți care dintre cele două îl construiți înainte de a alege unde locuiește codul. Cea mai mare parte a confuziei de aici vine din a construi una și a o aștepta pe cealaltă.

Deconectarea este un eveniment al sistemului de fișiere, nu un eveniment al cârligului

O deconectare planificată ar trebui să încheie operațiile de fișiere și să demonteze din sesiunea utilizatorului care montează cu comanda acceptată pentru acel tip de sistem de fișiere. Forțarea unei detașări pentru ca un cârlig să revină repede este modul în care aplicațiile își pierd directorul de lucru, iar utilizatorii încrederea în automatizare. O montare ocupată are nevoie de o decizie la nivelul aplicației, cum ar fi închiderea fișierului sau oprirea scrierii, nu de un semnal mai puternic. Starea de ieșire a cârligului nu este ceea ce se optimizează.

fusermount3 -u "$HOME/mnt/team"

Pierderea neașteptată este un caz diferit, iar SSHFS documentează că o operație întreruptă se poate bloca în timp ce transportul se reconectează.

Opțiunea de reconectare restaurează transportul, iar fișierele deschise înainte de acea reconectare pot returna în continuare erori și trebuie redeschise. Un VPN care revine nu dovedește nimic despre descriptori anteriori sau despre lucru nesalvat. Alegeți comportamentul dorit la o întrerupere — pauză, afișarea unei erori sau remontare intenționată — și testați-l cu fișiere de unică folosință înainte ca ceva să depindă de el.