Limigi Samba-kunhavigon al unu uzanto kaj unu VPN-adreso

En ĉi tiu dizajno konfuziĝas du malsamaj permesoj: kiu rajtas uzi dosierujon, kaj kiuj adresoj rajtas entute konektiĝi. Skribi kontoliston apud fontolisto sentiĝas kiel parigo, sed Samba taksas la du listojn kiel sendependajn predikatojn. Akceptiĝas ĉiu, kiu plenumas ambaŭ, kio estas pli larĝa regulo ol plej multaj administrantoj intencas. La solvo estas aŭ alia aranĝo de la kunhavigo, aŭ politika tavolo, kiu povas esprimi paron.

La mito: du listoj faras unu regulon

La referenco de smb.conf difinas valid users kaj hosts allow kiel du senrilatajn parametrojn, kaj ĝuste la agordo de ambaŭ sur unu kunhavigo estas kie la konfuzo komenciĝas. Agordu valid users = mira, tomas kaj hosts allow = 10.77.0.21, 10.77.0.22, kaj akceptiĝas kvar kombinaĵoj: Mira el ambaŭ adresoj, Tomas el ambaŭ adresoj. Nenio en la agordo ligas la unuan nomon al la unua adreso, kaj la ordo, en kiu la nomoj aperas, havas neniun signifon. Reordigi ilin, aldoni duan linion hosts allow aŭ meti unu nomon po linio ŝanĝas nenion. La rezulto estas la produto de du listoj, ne mapado inter ili.

Kion la plej multaj efektive volas, estas pli mallarĝa: Mira nur el unu adreso, Tomas nur el alia. Unu kunhaviga difino havas neniun sintakson por tiu ligo, kaj neniu lerta ordigo kreas ĝin. Tio estas politika formo, kiun Samba ne esprimas ene de unu kunhavigo, kaj tie la mito pluvivas.

Kion Samba taksas, kaj en kiu ordo

La etapoj funkcias laŭ fiksa ordo, kaj erara ordo produktas la malĝustan diagnozon. Kliento malfermas konekton; tutmonda gastiganta kontrolo funkcias se ĝi estas agordita; la seanca agordo aŭtentikigas la konton; tiam la kliento konektiĝas al kunhavigo, kie aplikiĝas ĝia propra gastiganta listo, valid users kaj la nurlega agordo; kaj nur kiam dosiero malfermiĝas, decidas la dosiersistemaj permesoj de la aŭtentikigita identeco. Ĉiu etapo povas mem rifuzi la peton, kaj trapasi unu diras nenion pri la sekva. La grava sekvo estas, ke la konto estas konata jam kiam la gastiganta listo de la kunhavigo taksiĝas, kaj la gastiganta listo ankoraŭ havas neniun rimedon nomi tiun konton.

Tial kunhavigo ne povas ligi unu uzanton al unu adreso: hosts allow kaj valid users estas apartaj predikatoj aplikataj en la sama arba konekta etapo, kaj ĉiu respondas al sia propra demando. La gastiganta predikato neniam prenas la kontan nomon kiel enigon, do ĝi ne povas esti skribita po uzanto. Nur dua kunhavigo, aŭ politika tavolo ekster Samba, povas esprimi la paron.

Tutmondaj valoroj gravas pro la maniero, kiel ili herediĝas. Kunhavigo, kiu preterlasas hosts allow, heredas la tutmondan valoron, kaj kunhavigo, kiu agordas sian propran, uzas tiun valoron anstataŭ la tutmonda, ne aldone al ĝi. Do larĝa tutmonda listo vastigas la kunhavigojn, kiuj neniam agordas la parametron, kaj faras nenion al kunhavigo, kiu difinas sian propran. Rulu testparm -s kaj legu la valorojn po kunhavigo, kiujn ĝi presas, ĉar tiu eligo estas la efektiva politiko, kaj la dosiero sur la disko ne estas.

Mallarĝigi unu kunhavigon ankaŭ faras nenion por la resto de la servilo. Aliaj kunhavigoj, printilaj atendovicoj kaj la IPC-konekto tenas siajn proprajn regulojn, do dizajno, kiu dependas de la adresolisto de unu kunhavigo, protektas unu vojon anstataŭ la gastiganton.

Du kunhavigaj nomoj super unu dosierujo

Kiam la sama dosierujo devas esti atingebla de du personoj el du adresoj, elmetu ĝin dufoje sub malsamaj nomoj. Ĉiu bloko portas unu konton kaj unu fonton, kio igas la paron io, kion la agordo povas devigi. La kosto estas, ke ĉiu persono uzas malsaman kunhavigan nomon por atingi la samajn dosierojn, kaj tio devas esti intenca ŝanĝo ĉe la klienta flanko.

[shared-mira]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = mira
    hosts allow = 10.77.0.21
    hosts deny = ALL

[shared-tomas]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = tomas
    hosts allow = 10.77.0.22
    hosts deny = ALL

Kunhaviga pordego ne estas dosiersistema permeso. Ambaŭ identecoj ankoraŭ bezonas aliron al la dosierujo tra la suba ACL, kaj la nurlega agordo estas dua tavolo, ne la sola. Donu skriban aliron nur se la laborfluo postulas ĝin, poste kontrolu, ke dosieroj kreitaj de unu identeco restas uzeblaj de la alia.

Ambaŭ blokoj montras al unu vojo, do ŝanĝo en la dosierujo efikas al ambaŭ kunhavigoj. Tio kutime estas la celo, sed ĝi ankaŭ signifas, ke eraro pri permesoj videblas al ambaŭ uzantoj samtempe.

Kion la fonta adreso povas pruvi

La adreso, kiun Samba vidas, estas la adreso, kiu atingis la servilon, ne la adreso, kiun la kliento kredas havi. VPN-pordego, kiu tradukas ĉiun klienton al unu fonta adreso, nuligas la distingon: ĉiuj klientoj alvenas kiel la sama gastiganto kaj la fontolisto ne plu povas distingi ilin. Stabila atribuo po kliento kaj pordego, kiu konservas la fonton, estas antaŭkondiĉoj por uzi adresojn kiel politikon entute. Sen ambaŭ, la limigo mezuras la pordegon anstataŭ la uzanton.

Eĉ tiam, adreso ne estas aparato. Du tekkomputiloj malantaŭ unu tunela adreso, realokita luo kaj kunhavigita laborejo ĉiuj kune refutas la supozon, ke fonto identigas personon. Traktu la limigon kiel retan amplekson kaj tenu aŭtentikigitajn SMB-kontojn kiel la identecan tavolon, kun aparata legitimilo kiel atestilo se vi bezonas aparatan rajtigon.

Tial ankaŭ la dizajno baras kunhavigojn kaj ne la servilon. Rifuzita paro ankoraŭ povas malfermi seancon, atingi alian kunhavigon aŭ listigi la servilon, kio estas alia rezulto ol aŭtentikiga malsukceso ĉe konekto. Se la postulo estas rifuzo antaŭ aŭtentikigo, la kunhavigaj parametroj de Samba estas la malĝusta ilo.

Pruvu ĝin per krucitaj paroj

Validigu la agordon, poste testu la kvar kombinaĵojn per novaj konektoj anstataŭ reuzita seanco. La celita paro devus atingi la dosierujon, kaj ambaŭ krucitaj paroj devus malsukcesi. Kaŝmemorita seanco el pli frua testo volonte respondos por la malĝusta kombinaĵo kaj igos rompitan regulon aspekti ĝusta.

testparm -s
smbclient //fileserver/shared-mira -U mira -c 'ls'
smbclient //fileserver/shared-tomas -U tomas -c 'ls'
smbstatus --shares

Sintaksa kontrolo pruvas nur, ke la dosiero analiziĝas. Legitimiloj, ACL-oj kaj la gastiganta decido ekzerciĝas per reala konekto, do rulu la klientan komandon el la adreso, kiun vi volas testi, kaj observu, kiu etapo rifuzas ĝin. Se krucita paro sukcesas, la efektiva gastiganta listo estas pli larĝa ol la bloko sugestas, kaj testparm -s estas la unua afero legenda. Se krucita paro malsukcesas pro la malĝusta kialo, suspektindas la konto aŭ la ACL.

Observi seancojn per smbstatus kaj mortigi ilin estas responda ago post kiam alirado komenciĝis, ne akcepta kontrolo. Bloki tutan observitan adreson ankaŭ povas malkonekti nerilatajn uzantojn malantaŭ la sama NAT, tial la decido apartenas al la kunhaviga difino kaj la observado al la responda procezo. Tenu la du aparte kaj la dizajno restas honesta pri tio, kion ĝi devigas.