Montimet SSHFS i përkasin përdoruesit, jo grepit të VPN

Supozimi thithet lehtë dhe vërehet vështirë: një grep lidhjeje VPN ekzekutohet si root, prandaj edhe montimi që nis ai duhet të organizohet si root. Ky arsyetim prodhon një drejtori ekipi që përdoruesi i desktopit nuk mund ta hapë, një montim që zhduket kur shërbimi nxitës riniset, dhe një kërkesë vërtetimi në një kontekst ku askush nuk mund t'i përgjigjet. Grepi dhe montimi janë dy punë të ndryshme, dhe vetëm njëra prej tyre ka nevojë për privilegje.

Miti: privilegji i rrjetit nënkupton privilegjin e montimit

Ngritja e një ndërfaqeje dhe vërtetimi në një server skedarësh janë aftësi të palidhura, dhe zakonisht i përkasin llogarive të ndryshme. Komponenti VPN ka nevojë për privilegje të mjaftueshme për të ndryshuar rrugët dhe ndërfaqet. Llogaria e serverit të skedarëve ka nevojë për një çelës ose fjalëkalim, një vendim për çelësin e hostit dhe një drejtori shtëpie ku të montojë. Dorëzimi i kredencialeve të punës së dytë identitetit të parë është mënyra se si një shërbim rrjeti përfundon duke mbajtur çelësin e një përdoruesi.

Në një laptop me një përdorues të vetëm ato mund të jenë e njëjta llogari, dhe kjo rastësi nuk është dizajn.

Sapo një grep me privilegje bën montimin, tre gjëra shkojnë keq në heshtje. Montimi zotërohet nga root, agjenti i përdoruesit mungon në atë mjedis, dhe dështimet shfaqen në regjistrin e shërbimit të rrjetit në vend të sesionit që i intereson. Asnjëra prej tyre nuk riparohet duke shtuar opsione në komandën e montimit. Ato riparohen duke i dhënë punën sesionit që zotëron identitetin.

Pse montimi i përket përdoruesit të identifikuar

Një montim SSHFS është një montim FUSE që zotërohet nga procesi që e krijoi, dhe aksesi ndjek atë pronësi dhe jo modalitetin e drejtorisë mëmë. Referenca rekomandon një përdorues të zakonshëm me një pikë montimi që ai përdorues zotëron, dhe pikërisht për këtë një montim i krijuar nga një proces root është i papërshtatshëm për të gjithë të tjerët. Një ndryshim lejesh në pikën e montimit nuk e riparon, sepse pengesa është vetë pronari i montimit.

Filloni me një bazë manuale brenda sesionit të përdoruesit: një pikë montimi e zbrazët ekzistuese nën drejtorinë shtëpiake, një llogari e autorizuar në server dhe një çelës hosti i verifikuar tashmë përmes procesit tuaj të miratuar. Montojeni me dorë një herë dhe përdoreni, sepse kjo provon se rruga e identitetit funksionon përpara se të ekzistojë ndonjë automatizim. Shënoni çfarë iu desh komandës: emrin e llogarisë, rrugën e eksportit dhe emrin privat të hostit. Mbani pikërisht atë kontekst për versionin e automatizuar, pasi një montim manual funksional është specifikimi që nxitësi duhet të riprodhojë.

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

Trajtoni çdo emër dhe rrugë në atë rresht si vendmbajtëse, duke përfshirë llogarinë dhe eksportin. Fjalëkalimi i një llogarie VPN nuk është automatikisht kredenciali i llogarisë së ruajtjes.

Çfarë duhet të kërkojë nxitësi nga sesioni

Rregullimi i mbështetur është një kërkesë nga ngjarja e rrjetit drejt sesionit të përdoruesit, jo një kredencial i huazuar. Kufizoni nxitësin në lidhjen që keni ndër mend, sipas emrit ose UUID, dhe jo në çdo ndërfaqe që quhet rastësisht tun0. Ky ndryshim i vetëm pengon një profil të dytë, një tunel provë ose sesionin e korrigjimit të një kolegu të nisë një montim.

Veprimi në anën e sesionit duhet të kërkojë montimin ekzistues të synuar dhe më pas të bëjë një tentativë të kufizuar.

Mos u përpiqni përsëri në çdo sondazh dhe mos vazhdoni të kërkoni kredenciale ndërsa serveri është i paarritshëm, sepse të dyja e kthejnë një ndërprerje kalimtare në një bllokim llogarie. Një shërbim pa mbikëqyrje është një dizajn i veçantë me kredencialet e veta të miratuara dhe rregullimin e vet të verifikimit të hostit në kontekstin e vet të ekzekutimit, dhe nuk mund të mbështetet se dikush ka zhbllokuar një agjent grafik. Vendosni cilin nga të dy po ndërtoni përpara se të zgjidhni ku jeton kodi. Pjesa më e madhe e konfuzionit këtu vjen nga ndërtimi i njërit dhe pritja e tjetrit.

Shkëputja është një ngjarje e sistemit të skedarëve, jo një ngjarje e grepit

Një shkëputje e planifikuar duhet të përfundojë operacionet e skedarëve dhe të çmontojë nga sesioni i përdoruesit që monton me komandën e mbështetur për atë lloj sistemi skedarësh. Forcimi i një shkëputjeje që grepi të kthehet shpejt është mënyra se si aplikacionet humbin drejtorinë e punës dhe përdoruesit humbin besimin në automatizim. Një montim i zënë ka nevojë për një vendim në nivel aplikacioni, si mbyllja e skedarit ose ndalimi i shkrimit, jo për një sinjal më të fortë. Statusi i daljes së grepit nuk është ajo që optimizohet.

fusermount3 -u "$HOME/mnt/team"

Humbja e papritur është një rast tjetër, dhe SSHFS dokumenton se një operacion i ndërprerë mund të bllokohet ndërsa transporti rilidhet.

Opsioni i rilidhjes rivendos transportin, dhe skedarët e hapur përpara asaj rilidhjeje mund të kthejnë ende gabime dhe të kenë nevojë të rihapën. Një VPN që kthehet nuk provon asgjë për dorezat e mëparshme ose punën e paruajtur. Zgjidhni sjelljen që dëshironi në një ndërprerje — pauzim, shfaqje gabimi ose rimontim me qëllim — dhe provojeni me skedarë të hedhshëm përpara se diçka të varet prej saj.