Připojení SSHFS patří uživateli, ne VPN háku

Předpoklad se snadno vstřebá a těžko si ho všimnete: háček připojení VPN běží jako root, takže i připojení, které spouští, by mělo být zařízeno jako root. Taková úvaha vede k týmovému adresáři, který uživatel plochy nemůže otevřít, k připojení, které zmizí při restartu spouštěcí služby, a k výzvě k autentizaci v kontextu, kde na ni nikdo nemůže odpovědět. Háček a připojení jsou dvě různé úlohy a jen jedna z nich potřebuje privilegium.

Mýtus: síťové privilegium znamená privilegium připojení

Zvednutí rozhraní a autentizace na souborovém serveru jsou nesouvisející schopnosti a obvykle patří různým účtům. Komponenta VPN potřebuje dost privilegií ke změně tras a rozhraní. Účet souborového serveru potřebuje klíč nebo heslo, rozhodnutí o klíči hostitele a domovský adresář, kam se připojuje. Předání přihlašovacích údajů druhé úlohy první identitě je způsob, jak síťová služba skončí s klíčem uživatele.

Na notebooku s jedním uživatelem to může být stejný účet a tato shoda není návrh.

Jakmile privilegovaný háček provede připojení, tři věci se tiše pokazí. Připojení vlastní root, uživatelův agent v tom prostředí chybí a selhání se objeví v protokolu síťové služby, ne v relaci, které na tom záleží. Nic z toho se nespraví přidáním voleb do příkazu pro připojení. Spraví se to tím, že se úloha předá relaci, která identitu vlastní.

Proč připojení patří přihlášenému uživateli

Připojení SSHFS je připojení FUSE vlastněné procesem, který ho vytvořil, a přístup se řídí tímto vlastnictvím, ne režimem nadřazeného adresáře. Referenční dokumentace doporučuje běžného uživatele s přípojným bodem, který tento uživatel vlastní, a právě proto je připojení vytvořené procesem root pro všechny ostatní nepohodlné. Změna oprávnění na přípojném bodě to nespraví, protože překážkou je vlastník samotného připojení.

Začněte ruční základní linií v uživatelské relaci: existující prázdný přípojný bod v domovském adresáři, autorizovaný účet na serveru a klíč hostitele už ověřený vaším schváleným postupem. Připojte ho jednou ručně a používejte ho, protože tím se prokáže, že cesta identity funguje dřív, než existuje jakákoli automatizace. Poznamenejte si, co příkaz potřeboval: název účtu, cestu exportu a soukromé jméno hostitele. Zachovejte přesně tento kontext pro automatizovanou verzi, protože funkční ruční připojení je specifikace, kterou musí spouštěč reprodukovat.

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

Každý název a cestu v tomto řádku považujte za zástupný údaj, včetně účtu a exportu. Heslo účtu VPN není automaticky přihlašovacím údajem účtu úložiště.

Co má spouštěč požádat relaci, aby udělala

Podporované uspořádání je požadavek ze síťové události do uživatelské relace, nikoli vypůjčený přihlašovací údaj. Omezte spouštěč na spojení, které máte na mysli, podle názvu nebo UUID, a ne na jakékoli rozhraní, které se náhodou jmenuje tun0. Tato jediná změna zabrání druhému profilu, testovacímu tunelu nebo kolegově ladicí relaci spustit připojení.

Akce na straně relace má najít zamýšlené existující připojení a pak provést jeden omezený pokus.

Nezkoušejte to znovu při každém dotazování a nevyžadujte přihlašovací údaj, dokud je server nedostupný, protože obojí mění krátkodobý výpadek v uzamčení účtu. Služba bez dozoru je samostatný návrh s vlastními schválenými přihlašovacími údaji a vlastním uspořádáním ověření hostitele ve vlastním kontextu spuštění a nemůže spoléhat na to, že někdo odemkl grafického agenta. Rozhodněte se, kterou z těch dvou věcí stavíte, dřív než zvolíte, kde bude kód žít. Většina zmatení tady vzniká tím, že se staví jedna a očekává druhá.

Odpojení je událost souborového systému, ne událost háčku

Plánované odpojení má dokončit souborové operace a odpojit z relace připojujícího uživatele podporovaným příkazem pro daný typ souborového systému. Vynucené odpojení, aby se háček rychle vrátil, je způsob, jak aplikace ztratí pracovní adresář a uživatelé důvěru v automatizaci. Zaneprázdněné připojení potřebuje rozhodnutí na úrovni aplikace, například zavřít soubor nebo zastavit zápis, ne silnější signál. Návratový stav háčku není to, co se optimalizuje.

fusermount3 -u "$HOME/mnt/team"

Neočekávaná ztráta je jiný případ a SSHFS dokumentuje, že přerušená operace může blokovat, dokud se transport znovu nepřipojí.

Volba opětovného připojení obnoví transport a soubory otevřené před tímto opětovným připojením mohou stále vracet chyby a potřebovat znovu otevřít. Vracející se VPN nic nedokazuje o dřívějších popisovačích ani o neuložené práci. Zvolte chování, které při výpadku chcete — pozastavení, zobrazení chyby nebo úmyslné znovupřipojení — a otestujte ho s jednorázovými soubory, než na něm bude co záviset.