Egy Samba-megosztás korlátozása egy felhasználóra és egy VPN-címre

Ebben a tervben két különböző engedély keveredik: ki használhat egy könyvtárat, és mely címek csatlakozhatnak egyáltalán. Egy fióklista írása egy forráslista mellé párosításnak tűnik, de a Samba a két listát egymástól független predikátumokként értékeli. Mindenkit beengednek, aki mindkettőt teljesíti, ami szélesebb szabály, mint amit a legtöbb rendszergazda szándékozik. A megoldás vagy egy másik megosztási elrendezés, vagy egy szabályzatréteg, amely ki tudja fejezni a párt.

A mítosz: két lista egy szabályt ad

Az smb.conf-referencia valid users és hosts allow paramétert két független paraméterként definiálja, és a zavar ott kezdődik, hogy mindkettőt egy megosztásra állítják. Állítsa be valid users = mira, tomas és hosts allow = 10.77.0.21, 10.77.0.22 értékét, és négy kombinációt fogadnak el: Mira bármelyik címről, Tomas bármelyik címről. Semmi a konfigurációban nem köti az első nevet az első címhez, és a nevek megjelenési sorrendjének nincs jelentése. Az átrendezésük, egy második hosts allow sor hozzáadása vagy soronként egy név elhelyezése nem változtat semmit. Az eredmény két lista szorzata, nem leképezés közöttük.

Amit a legtöbb ember valójában akar, az szűkebb: Mira csak egy címről, Tomas csak egy másikról. Egyetlen megosztásdefiníciónak nincs szintaxisa ehhez a kötéshez, és semmilyen ötletes sorrend nem hozza létre. Ez olyan szabályzatforma, amelyet a Samba egy megosztáson belül nem fejez ki, és itt marad fenn a mítosz.

Mit értékel a Samba, és milyen sorrendben

A szakaszok rögzített sorrendben futnak, és a rossz sorrend rossz diagnózist ad. Az ügyfél kapcsolatot nyit; globális gazdagép-ellenőrzés fut, ha van ilyen beállítva; a munkamenet beállítása hitelesíti a fiókot; majd az ügyfél csatlakozik egy megosztáshoz, ahol az adott megosztás saját gazdagép-listája, valid users és a csak olvasható beállítás érvényesül; és csak amikor egy fájlt megnyitnak, döntenek a hitelesített identitás fájlrendszer-engedélyei. Mindegyik szakasz önmagában is elutasíthatja a kérést, és az egyik átjutása semmit sem mond a következőről. A fontos következmény, hogy a fiók már ismert, mire a megosztás gazdagép-listáját értékelik, és a gazdagép-listának még mindig nincs módja megnevezni ezt a fiókot.

Ezért egy megosztás nem köthet egy felhasználót egy címhez: hosts allow és valid users külön predikátumok, amelyek ugyanabban a fa-csatlakozási szakaszban érvényesülnek, és mindegyik a saját kérdésére válaszol. A gazdagép-predikátum soha nem veszi bemenetként a fiók nevét, ezért nem írható felhasználónként. A párt csak egy második megosztás vagy a Sambán kívüli szabályzatréteg fejezheti ki.

A globális értékek az öröklés módja miatt fontosak. Az a megosztás, amely kihagyja a hosts allow beállítást, örökli a globális értéket, és az a megosztás, amely sajátot állít be, azt használja a globális helyett, nem mellette. Így egy széles globális lista kiszélesíti azokat a megosztásokat, amelyek soha nem állítják be a paramétert, és semmit nem tesz egy olyan megosztással, amely sajátot határoz meg. Futtassa a testparm -s parancsot, és olvassa el az általa kiírt megosztásonkénti értékeket, mert az a kimenet a tényleges szabályzat, a lemezen lévő fájl nem.

Egy megosztás szűkítése sem tesz semmit a kiszolgáló többi részével. A többi megosztás, a nyomtatási sorok és az IPC-kapcsolat a saját szabályait tartja, ezért az a terv, amely egy megosztás címlistájára támaszkodik, egy útvonalat véd, nem a gazdagépet.

Két megosztásnév egy könyvtár felett

Amikor ugyanannak a könyvtárnak két ember számára két címről elérhetőnek kell lennie, tegye elérhetővé kétszer, különböző nevekkel. Minden blokk egy fiókot és egy forrást hordoz, ami a párt olyasmivé teszi, amit a konfiguráció kikényszeríthet. Az ára az, hogy mindenki más megosztásnevet használ ugyanazoknak a fájloknak az eléréséhez, és ennek szándékos ügyféloldali változásnak kell lennie.

[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

A megosztás kapuja nem fájlrendszer-engedély. Mindkét identitásnak továbbra is szüksége van a könyvtárhoz való hozzáférésre a mögöttes ACL-en keresztül, és a csak olvasható beállítás egy második réteg, nem az egyetlen. Csak akkor adjon írási hozzáférést, ha a munkafolyamat megköveteli, majd ellenőrizze, hogy az egyik identitás által létrehozott fájlok használhatók maradnak-e a másik számára.

Mindkét blokk egy útvonalra mutat, így a könyvtár változása mindkét megosztást érinti. Általában ez a cél, de azt is jelenti, hogy egy engedélyhiba mindkét felhasználó számára egyszerre látható.

Mit bizonyíthat a forráscím

A Samba által látott cím az a cím, amely elérte a kiszolgálót, nem az, amelyet az ügyfél hisz magáénak. Egy VPN-átjáró, amely minden ügyfelet egyetlen forráscímre fordít, megszünteti a különbséget: minden ügyfél ugyanazon gazdagépként érkezik, és a forráslista már nem tudja megkülönböztetni őket. Az ügyfelenkénti stabil kiosztás és a forrást megőrző átjáró előfeltételei annak, hogy a címeket egyáltalán szabályzatként használjuk. Mindkettő nélkül a korlátozás az átjárót méri, nem a felhasználót.

Még akkor sem eszköz egy cím. Két laptop egy alagútcím mögött, egy újra kiosztott bérlet és egy megosztott munkaállomás együtt cáfolja azt a feltevést, hogy egy forrás egy személyt azonosít. Kezelje a korlátozást hálózati hatókörként, és tartsa a hitelesített SMB-fiókokat identitásrétegként, eszközhitelesítővel, például tanúsítvánnyal, ha eszközengedélyezésre van szüksége.

Ezért is zárja a terv a megosztásokat, és nem a kiszolgálót. Egy elutasított pár még mindig nyithat munkamenetet, elérhet egy másik megosztást vagy listázhatja a kiszolgálót, ami más eredmény, mint egy hitelesítési hiba csatlakozáskor. Ha a követelmény a hitelesítés előtti elutasítás, a Samba megosztási paraméterei a rossz eszköz.

Bizonyítsa keresztezett párokkal

Érvényesítse a konfigurációt, majd tesztelje a négy kombinációt friss kapcsolatokkal, nem újrahasznált munkamenettel. A szándékolt párnak el kell érnie a könyvtárat, és mindkét keresztezett párnak meg kell buknia. Egy korábbi teszt gyorsítótárazott munkamenete készséggel válaszol a rossz kombinációra, és egy törött szabályt helyesnek mutat.

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

A szintaxis-ellenőrzés csak azt bizonyítja, hogy a fájl elemezhető. A hitelesítő adatokat, az ACL-eket és a gazdagép-döntést valódi kapcsolat gyakorolja, ezért futtassa az ügyfélparancsot arról a címről, amelyet tesztelni akar, és figyelje, melyik szakasz utasítja el. Ha egy keresztezett pár sikerül, a tényleges gazdagép-lista szélesebb, mint a blokk sugallja, és a testparm -s az első, amit el kell olvasni. Ha egy keresztezett pár rossz okból bukik meg, a fiók vagy az ACL a gyanús.

A munkamenetek smbstatus segítségével történő megfigyelése és leállítása a hozzáférés megkezdése utáni reagálás, nem belépés-ellenőrzés. Egy teljes megfigyelt cím blokkolása az ugyanazon NAT mögötti, nem kapcsolódó felhasználókat is leválaszthatja, ezért a döntés a megosztásdefinícióhoz, a megfigyelés pedig a reagálási folyamathoz tartozik. Tartsa a kettőt külön, és a terv őszinte marad abban, amit kikényszerít.