Pripojenia SSHFS patria používateľovi, nie VPN háku

Predpoklad sa ľahko vstrebáva a ťažko si ho všimneme: háčik pripojenia VPN beží ako root, takže aj pripojenie, ktoré spúšťa, by malo byť zariadené ako root. Taká úvaha vedie k tímovému adresáru, ktorý používateľ plochy nemôže otvoriť, k pripojeniu, ktoré zmizne pri reštarte spúšťacej služby, a k výzve na autentifikáciu v kontexte, kde na ňu nikto nemôže odpovedať. Háčik a pripojenie sú dve rôzne úlohy a iba jedna z nich potrebuje privilegium.

Mýtus: sieťové privilegium znamená privilegium pripojenia

Zdvihnutie rozhrania a autentifikácia na súborovom serveri sú nesúvisiace schopnosti a zvyčajne patria rôznym účtom. Komponent VPN potrebuje dostatok privilegií na zmenu trás a rozhraní. Účet súborového servera potrebuje kľúč alebo heslo, rozhodnutie o kľúči hostiteľa a domovský adresár, do ktorého sa pripája. Odovzdanie prihlasovacích údajov druhej úlohy prvej identite je spôsob, akým sieťová služba skončí s kľúčom používateľa.

Na notebooku s jedným používateľom to môže byť ten istý účet a tá zhoda nie je návrh.

Keď privilegovaný háčik vykoná pripojenie, tri veci sa ticho pokazia. Pripojenie vlastní root, agent používateľa v tom prostredí chýba a zlyhania sa objavia v protokole sieťovej služby, nie v relácii, ktorej na tom záleží. Nič z toho sa neopraví pridaním volieb do príkazu na pripojenie. Opraví sa to odovzdaním úlohy relácii, ktorá vlastní identitu.

Prečo pripojenie patrí prihlásenému používateľovi

Pripojenie SSHFS je pripojenie FUSE vlastnené procesom, ktorý ho vytvoril, a prístup sa riadi týmto vlastníctvom, nie režimom nadradeného adresára. Referencia odporúča bežného používateľa s prípojným bodom, ktorý tento používateľ vlastní, a práve preto je pripojenie vytvorené procesom root pre všetkých ostatných nepohodlné. Zmena oprávnení na prípojnom bode to neopraví, pretože prekážkou je vlastník samotného pripojenia.

Začnite ručnou základnou líniou v používateľskej relácii: existujúci prázdny prípojný bod v domovskom adresári, autorizovaný účet na serveri a kľúč hostiteľa už overený vaším schváleným postupom. Pripojte ho raz ručne a používajte ho, pretože to dokazuje, že cesta identity funguje skôr, než existuje akákoľvek automatizácia. Poznamenajte si, čo príkaz potreboval: názov účtu, cestu exportu a súkromné meno hostiteľa. Zachovajte presne tento kontext pre automatizovanú verziu, pretože funkčné ručné pripojenie je špecifikácia, ktorú musí spúšťač reprodukovať.

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

Každý názov a cestu v tomto riadku považujte za zástupný údaj, vrátane účtu a exportu. Heslo účtu VPN nie je automaticky prihlasovacím údajom účtu úložiska.

Čo má spúšťač požiadať reláciu, aby urobila

Podporované usporiadanie je požiadavka zo sieťovej udalosti do používateľskej relácie, nie požičaný prihlasovací údaj. Obmedzte spúšťač na spojenie, ktoré máte na mysli, podľa názvu alebo UUID, a nie na akékoľvek rozhranie, ktoré sa náhodou volá tun0. Tá jediná zmena zabráni druhému profilu, testovaciemu tunelu alebo kolegovej ladiacej relácii spustiť pripojenie.

Akcia na strane relácie má nájsť zamýšľané existujúce pripojenie a potom urobiť jeden obmedzený pokus.

Neskúšajte znova pri každom dopytovaní a nežiadajte stále prihlasovací údaj, kým je server nedostupný, pretože oboje mení krátkodobý výpadok na uzamknutie účtu. Služba bez dozoru je samostatný návrh s vlastnými schválenými prihlasovacími údajmi a vlastným usporiadaním overenia hostiteľa vo vlastnom kontexte spustenia a nemôže sa spoliehať na to, že niekto odomkol grafického agenta. Rozhodnite sa, ktorú z tých dvoch vecí staviate, skôr než zvolíte, kde bude kód žiť. Väčšina zmätku tu vzniká tým, že sa stavia jedna a očakáva druhá.

Odpojenie je udalosť súborového systému, nie udalosť háčika

Plánované odpojenie má dokončiť súborové operácie a odpojiť z relácie pripájajúceho používateľa podporovaným príkazom pre daný typ súborového systému. Vynútené odpojenie, aby sa háčik rýchlo vrátil, je spôsob, akým aplikácie stratia pracovný adresár a používatelia dôveru v automatizáciu. Zaneprázdnené pripojenie potrebuje rozhodnutie na úrovni aplikácie, napríklad zavrieť súbor alebo zastaviť zápis, nie silnejší signál. Návratový stav háčika nie je to, čo sa optimalizuje.

fusermount3 -u "$HOME/mnt/team"

Neočakávaná strata je iný prípad a SSHFS dokumentuje, že prerušená operácia môže blokovať, kým sa transport znova nepripojí.

Voľba opätovného pripojenia obnoví transport a súbory otvorené pred týmto opätovným pripojením môžu stále vracať chyby a potrebovať znova otvoriť. Vracajúca sa VPN nič nedokazuje o skorších popisovačoch ani o neuloženej práci. Zvoľte správanie, ktoré pri výpadku chcete — pozastavenie, zobrazenie chyby alebo úmyselné opätovné pripojenie — a otestujte ho s jednorazovými súbormi, kým na ňom bude čokoľvek závisieť.