SSHFS-i mount'id kuuluvad kasutajale, mitte VPN-konksule

Eeldust on lihtne omaks võtta ja raske märgata: VPN-ühenduse konks jookseb rootina, seega peaks ka selle käivitatav mount olema korraldatud rootina. See arutluskäik tekitab meeskonnakataloogi, mida töölaua kasutaja avada ei saa, mount'i, mis kaob päästiku teenuse taaskäivitamisel, ja autentimisküsimuse kontekstis, kus keegi ei saa sellele vastata. Konks ja mount on kaks erinevat tööd ning ainult üks neist vajab privileegi.

Müüt: võrguprivileeg tähendab mount'imisprivileegi

Liidese tõstmine ja failiserverisse autentimine on omavahel seostamata võimed ning kuuluvad tavaliselt eri kontodele. VPN-i komponendil on vaja piisavat privileegi marsruutide ja liideste muutmiseks. Failiserveri kontol on vaja võtit või parooli, otsust hostivõtme kohta ja kodukataloogi, kuhu mountida. Teise töö volituste andmine esimesele identiteedile on viis, kuidas võrguteenus jääb kasutaja võtit hoidma.

Ühe kasutaja sülearvutis võib see olla sama konto ja see kokkusattumus ei ole disain.

Kui privilegeeritud konks on mount'imise teinud, läheb kolm asja vaikselt valesti. Mount kuulub rootile, kasutaja agent puudub sellest keskkonnast ja vead ilmuvad võrguteenuse logisse, mitte seansi, mille jaoks see oluline on. Ükski neist ei parane mount-käsklusele valikute lisamisega. Need paranevad, kui töö antakse seansile, mis identiteeti omab.

Miks mount kuulub sisse logitud kasutajale

SSHFS-i mount on FUSE-mount, mis kuulub selle loonud protsessile, ja juurdepääs järgib seda omandit, mitte ülemkataloogi režiimi. Viide soovitab tavalist kasutajat, kellele kuulub mount-punkt, ja täpselt seetõttu on root-protsessi loodud mount kõigile teistele ebamugav. Õiguste muutmine mount-punktil ei paranda seda, sest takistuseks on mount'i oma omanik.

Alustage käsitsi baasjoonega kasutaja seansi sees: olemasolev tühi mount-punkt kodukataloogi all, serveris volitatud konto ja hostivõti, mis on juba teie kinnitatud protsessi kaudu kontrollitud. Mountige seda üks kord käsitsi ja kasutage seda, sest see tõestab, et identiteedi tee töötab enne mis tahes automatiseerimist. Pange kirja, mida käsk vajas: konto nimi, ekspordi tee ja privaatne hostinimi. Hoidke täpselt seda konteksti automatiseeritud versiooni jaoks, sest töötav käsitsi mount on spetsifikatsioon, mida päästik peab taastootma.

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

Käsitlege iga nime ja teed selles reas kohahoidjana, sealhulgas kontot ja eksporti. VPN-i konto parool ei ole automaatselt salvestuskonto volitus.

Mida peaks päästik seansilt paluma

Toetatud korraldus on võrgusündmusest kasutaja seansile saadetud taotlus, mitte laenatud volitus. Piiritlege päästik ühendusega, mida mõtlete, nime või UUID järgi, mitte mis tahes liidesega, mis juhtub olema tun0. See üks muudatus takistab teisel profiilil, testtunnelil või kolleegi silumisseansil mount'i käivitamast.

Seansi poolne tegevus peaks otsima kavandatud olemasolevat mount'i ja tegema seejärel ühe piiratud katse.

Ärge proovige uuesti igal küsitlusel ega nõudke volitusi, kuni server on kättesaamatu, sest mõlemad muudavad lühiajalise katkestuse konto lukustuseks. Järelevalveta teenus on eraldi disain oma kinnitatud volituste ja oma hostikontrolli korraldusega oma täitmiskontekstis ning see ei saa loota, et keegi on graafilise agendi avanud. Otsustage, kumba kahest te ehitate, enne kui valite, kus kood elab. Suurem osa segadusest siin tuleb sellest, et ehitatakse ühte ja oodatakse teist.

Ühenduse katkestamine on failisüsteemi sündmus, mitte konksu sündmus

Planeeritud katkestamine peaks failitoimingud lõpetama ja mount'ima lahti mountiva kasutaja seansist selle failisüsteemitüübi jaoks ettenähtud käsuga. Eralduse sundimine, et konks kiiresti naaseks, on viis, kuidas rakendused kaotavad oma töökataloogi ja kasutajad usalduse automatiseerimise vastu. Hõivatud mount vajab rakendustasandi otsust, näiteks faili sulgemist või kirjutamise peatamist, mitte tugevamat signaali. Konksu väljumisolek ei ole see, mida optimeeritakse.

fusermount3 -u "$HOME/mnt/team"

Ootamatu kadu on teine juhtum ja SSHFS dokumenteerib, et katkenud toiming võib blokeeruda, kuni transport uuesti ühendub.

Taasühenduse valik taastab transpordi ja enne seda taasühendust avatud failid võivad endiselt vigu tagastada ning vajada uuesti avamist. Naasev VPN ei tõesta midagi varasemate pidemete ega salvestamata töö kohta. Valige käitumine, mida katkestuse korral soovite — paus, vea näitamine või teadlik uuesti mount'imine — ja testige seda ühekordsete failidega, enne kui miski sellest sõltub.