Begränsa en Samba-delning till en användare och en VPN-adress

I den här designen blandas två olika behörigheter: vem som får använda en katalog och vilka adresser som alls får ansluta. Att skriva en kontolista bredvid en källista känns som en parning, men Samba bedömer de två listorna som oberoende predikat. Alla som uppfyller båda släpps in, och det är en vidare regel än de flesta administratörer avser. Lösningen är antingen en annan delningslayout eller ett policylager som kan uttrycka paret.

Myten: två listor ger en regel

smb.conf-referensen definierar valid users och hosts allow som två oberoende parametrar, och det är när båda sätts på en delning som förvirringen börjar. Sätt valid users = mira, tomas och hosts allow = 10.77.0.21, 10.77.0.22 och fyra kombinationer släpps in: Mira från endera adressen, Tomas från endera adressen. Inget i konfigurationen binder det första namnet till den första adressen, och ordningen namnen står i betyder ingenting. Att ordna om dem, lägga till ännu en hosts allow-rad eller sätta ett namn per rad ändrar ingenting. Resultatet är produkten av två listor, inte en koppling mellan dem.

Det de flesta faktiskt vill ha är snävare: Mira bara från en adress, Tomas bara från en annan. En enda delningsdefinition har ingen syntax för den bindningen, och ingen mängd smart ordning skapar en. Det är en policyform som Samba inte uttrycker inom en delning, och det är där myten överlever.

Vad Samba bedömer, och i vilken ordning

Faserna körs i fast ordning, och fel ordning ger fel diagnos. En klient öppnar en anslutning; en global värdkontroll körs om en är konfigurerad; sessionsuppsättningen autentiserar kontot; sedan ansluter klienten till en delning, där delningens egen värdlista, valid users och skrivskyddet tillämpas; och först när en fil öppnas avgör filsystembehörigheterna för den autentiserade identiteten. Varje steg kan avvisa begäran självt, och att passera ett säger ingenting om nästa. Den viktiga konsekvensen är att kontot redan är känt när delningens värdlista bedöms, och värdlistan har fortfarande inget sätt att namnge det kontot.

Därför kan en delning inte binda en användare till en adress: hosts allow och valid users är separata predikat som tillämpas i samma trädanslutningssteg, och var och en svarar på sin egen fråga. Värdpredikatet tar aldrig kontonamnet som indata, så det kan inte skrivas per användare. Bara en andra delning, eller ett policylager utanför Samba, kan uttrycka paret.

Globala värden spelar roll på grund av hur de ärvs. En delning som utelämnar hosts allow ärver det globala värdet, och en delning som sätter sitt eget använder det värdet i stället för det globala, inte utöver det. Så en bred global lista vidgar de delningar som aldrig sätter parametern och gör ingenting med en delning som definierar sitt eget. Kör testparm -s och läs värdena per delning som den skriver ut, för den utskriften är den effektiva policyn, och filen på disken är det inte.

Att snäva in en delning gör inte heller något för resten av servern. Andra delningar, skrivarköer och IPC-anslutningen behåller sina egna regler, så en design som vilar på en delnings adresslista skyddar en väg i stället för värden.

Två delningsnamn över en katalog

När samma katalog måste kunna nås av två personer från två adresser, exponera den två gånger under olika namn. Varje block bär ett konto och en källa, vilket gör paret till något konfigurationen kan genomdriva. Priset är att varje person använder ett annat delningsnamn för att nå samma filer, och det måste vara en medveten ändring på klientsidan.

[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

En delningsport är inte en filsystembehörighet. Båda identiteterna behöver fortfarande åtkomst till katalogen via den underliggande ACL:en, och skrivskyddet är ett andra lager, inte det enda. Ge skrivåtkomst bara om arbetsflödet kräver det, och kontrollera sedan att filer som skapats av den ena identiteten förblir användbara för den andra.

Båda blocken pekar på en väg, så en ändring i katalogen påverkar båda delningarna. Det är oftast poängen, men det betyder också att ett behörighetsfel syns för båda användarna samtidigt.

Vad källadressen kan bevisa

Adressen Samba ser är adressen som nådde servern, inte adressen klienten tror sig ha. En VPN-gateway som översätter varje klient till en enda källadress upphäver skillnaden: alla klienter anländer som samma värd och källistan kan inte längre skilja dem. Stabil tilldelning per klient och en gateway som bevarar källan är förutsättningar för att använda adresser som policy över huvud taget. Utan båda mäter begränsningen gatewayen i stället för användaren.

Ändå är en adress inte en enhet. Två bärbara datorer bakom en tunneladress, en omfördelad lease och en delad arbetsstation motbevisar alla antagandet att en källa identifierar en person. Behandla begränsningen som nätverksomfång och håll autentiserade SMB-konton som identitetslagret, med en enhetslegitimation som ett certifikat om du behöver enhetsauktorisering.

Det är också därför designen stänger delningar och inte servern. Ett avvisat par kan fortfarande öppna en session, nå en annan delning eller lista servern, vilket är ett annat utfall än ett autentiseringsfel vid anslutningen. Om kravet är avvisning före autentisering är Sambas delningsparametrar fel verktyg.

Bevisa det med korsade par

Validera konfigurationen och testa sedan de fyra kombinationerna med nya anslutningar i stället för en återanvänd session. Det avsedda paret ska nå katalogen, och båda de korsade paren ska misslyckas. En cachad session från ett tidigare test svarar gärna för fel kombination och får en trasig regel att se korrekt ut.

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

En syntaxkontroll bevisar bara att filen tolkas. Inloggningsuppgifter, ACL:er och värdbeslutet utövas av en faktisk anslutning, så kör klientkommandot från adressen du vill testa och se vilket steg som avvisar det. Om ett korsat par lyckas är den effektiva värdlistan bredare än blocket antyder, och testparm -s är det första som ska läsas. Om ett korsat par misslyckas av fel skäl är kontot eller ACL:en den misstänkta.

Att övervaka sessioner med smbstatus och stänga dem är en responsåtgärd efter att åtkomsten börjat, inte åtkomstkontroll. Att blockera en hel observerad adress kan också koppla från orelaterade användare bakom samma NAT, och därför hör beslutet till delningsdefinitionen och övervakningen till responsprocessen. Håll de två åtskilda och designen förblir ärlig om vad den genomdriver.