Ang mga mount ng SSHFS ay sa user, hindi sa hook ng VPN

Ang palagay ay madaling tanggapin at mahirap mapansin: ang hook ng koneksyon ng VPN ay tumatakbo bilang root, kaya ang mount na sinisimulan nito ay dapat ding ayusin bilang root. Ang pangangatwiran na iyon ay gumagawa ng direktoryo ng team na hindi mabuksan ng desktop user, isang mount na nawawala kapag nag-restart ang serbisyong trigger, at isang prompt ng authentication sa kontekstong walang makakasagot. Ang hook at ang mount ay dalawang magkaibang trabaho, at isa lang sa kanila ang nangangailangan ng pribilehiyo.

Ang mito: ang pribilehiyo ng network ay pribilehiyo ng mount

Ang pagtataas ng interface at ang pagpapatunay sa isang file server ay magkaibang kakayahan, at karaniwang kabilang sila sa magkaibang account. Ang bahagi ng VPN ay nangangailangan ng sapat na pribilehiyo para baguhin ang mga ruta at interface. Ang account ng file server ay nangangailangan ng key o password, desisyon tungkol sa host key, at home directory na pagmumuntan. Ang pagbibigay ng kredensyal ng ikalawang trabaho sa unang pagkakakilanlan ay ang paraan na ang isang serbisyo ng network ay nauuwi sa paghawak ng key ng user.

Sa isang laptop na isang user lang, maaaring pareho silang account, at ang pagkakataong iyon ay hindi disenyo.

Kapag ang isang privileged hook ay gumawa ng mount, tatlong bagay ang tahimik na nasisira. Ang mount ay pag-aari ng root, wala ang agent ng user sa environment na iyon, at ang mga pagkabigo ay lumalabas sa log ng serbisyo ng network kaysa sa session na may pakialam. Wala sa mga ito ang naaayos sa pamamagitan ng pagdaragdag ng opsyon sa mount command. Naaayos ang mga ito sa pamamagitan ng pagbibigay ng trabaho sa session na nagmamay-ari ng pagkakakilanlan.

Bakit ang mount ay sa naka-log in na user

Ang mount ng SSHFS ay isang mount ng FUSE na pag-aari ng prosesong lumikha nito, at ang pag-access ay sumusunod sa pagmamay-ari na iyon kaysa sa mode ng parent directory. Inirerekomenda ng reference ang isang ordinaryong user na may mount point na pag-aari niya, at iyon mismo ang dahilan kung bakit ang mount na ginawa ng prosesong root ay mahirap para sa lahat ng iba. Ang pagbabago ng pahintulot sa mount point ay hindi ito naaayos, dahil ang hadlang ay ang may-ari mismo ng mount.

Magsimula sa manual na baseline sa loob ng session ng user: mayroon nang walang laman na mount point sa ilalim ng home directory, awtorisadong account sa server, at host key na na-verify na sa pamamagitan ng iyong aprubadong proseso. I-mount ito nang manu-mano nang isang beses at gamitin, dahil pinatutunayan niyan na gumagana ang landas ng pagkakakilanlan bago pa man umiral ang anumang automation. Itala kung ano ang kailangan ng command: pangalan ng account, landas ng export at pribadong hostname. Panatilihin ang eksaktong kontekstong iyon para sa automated na bersyon, dahil ang gumaganang manual na mount ay ang espesipikasyong kailangang kopyahin ng trigger.

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

Ituring ang bawat pangalan at landas sa linyang iyon bilang placeholder, kasama ang account at export. Ang password ng account ng VPN ay hindi awtomatikong kredensyal ng account ng imbakan.

Ano ang dapat hilingin ng trigger sa session

Ang sinusuportahang kaayusan ay isang kahilingan mula sa kaganapan ng network patungo sa session ng user, hindi hiram na kredensyal. Limitahan ang trigger sa koneksyong tinutukoy mo, sa pangalan o UUID, at hindi sa anumang interface na nagkataong tinatawag na tun0. Ang nag-iisang pagbabagong iyon ay humahadlang sa ikalawang profile, test tunnel o session ng pag-debug ng kasamahan na magsimula ng mount.

Ang aksyon sa panig ng session ay dapat hanapin ang nilalayong umiiral na mount at pagkatapos ay gumawa ng isang limitadong pagtatangka.

Huwag subukang muli sa bawat polling, at huwag magpatuloy sa paghingi ng kredensyal habang hindi maabot ang server, dahil pareho nilang ginagawang lockout ng account ang pansamantalang pagkagambala. Ang serbisyong walang pangangasiwa ay hiwalay na disenyo na may sariling aprubadong kredensyal at sariling kaayusan ng pag-verify ng host sa sarili nitong konteksto ng pagpapatupad, at hindi ito makakaasa na may nag-unlock ng graphical agent. Magpasya kung alin sa dalawa ang ginagawa mo bago piliin kung saan nakatira ang code. Karamihan ng kalituhan dito ay nagmumula sa paggawa ng isa at pag-asa sa isa pa.

Ang pagdiskonekta ay kaganapan ng file system, hindi kaganapan ng hook

Ang planadong pagdiskonekta ay dapat tapusin ang mga operasyon ng file at mag-unmount mula sa session ng user na nag-mount gamit ang sinusuportahang command para sa uri ng file system na iyon. Ang pagpilit ng paghihiwalay upang mabilis na bumalik ang hook ay ang paraan na nawawala ng mga aplikasyon ang kanilang working directory at nawawala ng mga user ang tiwala sa automation. Ang abalang mount ay nangangailangan ng desisyon sa antas ng aplikasyon, tulad ng pagsasara ng file o paghinto ng pagsulat, hindi mas malakas na signal. Ang exit status ng hook ay hindi ang bagay na ina-optimize.

fusermount3 -u "$HOME/mnt/team"

Ang hindi inaasahang pagkawala ay ibang kaso, at itinatala ng SSHFS na ang naantala na operasyon ay maaaring humarang habang muling kumokonekta ang transport.

Ang opsyon ng muling pagkonekta ay nagbabalik ng transport, at ang mga file na binuksan bago ang muling pagkonektang iyon ay maaari pa ring magbalik ng mga error at kailangang muling buksan. Ang VPN na bumalik ay walang pinatutunayan tungkol sa mga naunang handle o hindi na-save na trabaho. Piliin ang pag-uugaling gusto mo kapag may pagkagambala — pag-pause, pagpapakita ng error o sadyang muling pag-mount — at subukan ito sa mga disposable na file bago umasa ang anuman dito.