Beperk een Samba-share tot één gebruiker en één VPN-adres

In dit ontwerp raken twee verschillende rechten verward: wie een map mag gebruiken, en welke adressen überhaupt mogen verbinden. Een accountlijst naast een bronnenlijst schrijven voelt als een koppeling, maar Samba beoordeelt de twee lijsten als onafhankelijke predicaten. Iedereen die beide vervult, wordt toegelaten, en dat is een bredere regel dan de meeste beheerders bedoelen. De oplossing is een andere share-indeling of een beleidslaag die het paar kan uitdrukken.

De mythe: twee lijsten maken één regel

De smb.conf-referentie definieert valid users en hosts allow als twee onafhankelijke parameters, en juist het instellen van beide op één share is waar de verwarring begint. Stel valid users = mira, tomas en hosts allow = 10.77.0.21, 10.77.0.22 in, en vier combinaties worden toegelaten: Mira vanaf beide adressen, Tomas vanaf beide adressen. Niets in de configuratie bindt de eerste naam aan het eerste adres, en de volgorde waarin de namen verschijnen heeft geen betekenis. Ze herordenen, een tweede hosts allow-regel toevoegen of één naam per regel zetten verandert niets. Het resultaat is het product van twee lijsten, geen koppeling ertussen.

Wat de meeste mensen echt willen, is smaller: Mira alleen vanaf één adres, Tomas alleen vanaf een ander. Eén sharedefinitie heeft geen syntaxis voor die binding, en geen enkele slimme ordening maakt er een. Dat is een beleidsvorm die Samba binnen één share niet uitdrukt, en daar overleeft de mythe.

Wat Samba beoordeelt, en in welke volgorde

De fasen lopen in een vaste volgorde, en een verkeerde volgorde geeft de verkeerde diagnose. Een client opent een verbinding; een globale hostcontrole loopt als die is geconfigureerd; de sessieopzet authenticeert het account; daarna verbindt de client met een share, waar de eigen hostlijst van die share, valid users en de alleen-lezen-instelling worden toegepast; en pas wanneer een bestand wordt geopend, beslissen de bestandssysteemrechten van de geauthenticeerde identiteit. Elke fase kan het verzoek zelf weigeren, en het passeren van één zegt niets over de volgende. De belangrijke consequentie is dat het account al bekend is wanneer de hostlijst van de share wordt beoordeeld, en de hostlijst heeft nog steeds geen manier om dat account te benoemen.

Daarom kan een share één gebruiker niet aan één adres binden: hosts allow en valid users zijn afzonderlijke predicaten die in dezelfde boom-verbindingsfase worden toegepast, en elk beantwoordt zijn eigen vraag. Het hostpredicaat neemt nooit de accountnaam als invoer, dus het kan niet per gebruiker worden geschreven. Alleen een tweede share, of een beleidslaag buiten Samba, kan het paar uitdrukken.

Globale waarden doen ertoe vanwege de manier waarop ze worden geërfd. Een share die hosts allow weglaat, erft de globale waarde, en een share die de eigen waarde instelt, gebruikt die waarde in plaats van de globale, niet daarnaast. Een brede globale lijst verbreedt dus de shares die de parameter nooit instellen, en doet niets met een share die de eigen waarde definieert. Voer testparm -s uit en lees de waarden per share die het afdrukt, want die uitvoer is het effectieve beleid, en het bestand op schijf is dat niet.

Het smaller maken van één share doet ook niets voor de rest van de server. Andere shares, printerwachtrijen en de IPC-verbinding houden hun eigen regels, dus een ontwerp dat op de adressenlijst van één share leunt, beschermt één pad en niet de host.

Twee sharenamen over één map

Wanneer dezelfde map voor twee mensen vanaf twee adressen bereikbaar moet zijn, stel hem dan twee keer beschikbaar onder verschillende namen. Elk blok draagt één account en één bron, wat het paar iets maakt dat de configuratie kan afdwingen. De prijs is dat elke persoon een andere sharenaam gebruikt om dezelfde bestanden te bereiken, en dat moet een bewuste wijziging aan de clientkant zijn.

[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

Een sharepoort is geen bestandssysteemrecht. Beide identiteiten hebben nog steeds toegang tot de map nodig via de onderliggende ACL, en de alleen-lezen-instelling is een tweede laag en niet de enige. Geef schrijftoegang alleen als de werkstroom het vereist, en controleer daarna dat bestanden die door de ene identiteit zijn gemaakt bruikbaar blijven voor de andere.

Beide blokken wijzen naar één pad, dus een wijziging in de map beïnvloedt beide shares. Dat is meestal het punt, maar het betekent ook dat een rechtenfout voor beide gebruikers tegelijk zichtbaar is.

Wat het bronadres kan bewijzen

Het adres dat Samba ziet, is het adres dat de server heeft bereikt, niet het adres dat de client denkt te hebben. Een VPN-gateway die elke client naar één bronadres vertaalt, heft het verschil op: alle clients komen binnen als dezelfde host en de bronnenlijst kan ze niet meer onderscheiden. Stabiele toewijzing per client en een gateway die de bron behoudt, zijn voorwaarden om adressen überhaupt als beleid te gebruiken. Zonder beide meet de beperking de gateway in plaats van de gebruiker.

Zelfs dan is een adres geen apparaat. Twee laptops achter één tunneladres, een opnieuw toegewezen lease en een gedeeld werkstation weerleggen allemaal de aanname dat een bron een persoon identificeert. Behandel de beperking als netwerkbereik en houd geauthenticeerde SMB-accounts als de identiteitslaag, met een apparaatbewijs zoals een certificaat als je apparaatautorisatie nodig hebt.

Daarom sluit het ontwerp shares af en niet de server. Een geweigerd paar kan nog steeds een sessie openen, een andere share bereiken of de server opsommen, wat een andere uitkomst is dan een authenticatiefout bij het verbinden. Als de eis weigering vóór authenticatie is, zijn Samba's shareparameters het verkeerde gereedschap.

Bewijs het met gekruiste paren

Valideer de configuratie en test daarna de vier combinaties met nieuwe verbindingen in plaats van een hergebruikte sessie. Het bedoelde paar moet de map bereiken, en beide gekruiste paren moeten mislukken. Een gecachte sessie van een eerdere test antwoordt graag voor de verkeerde combinatie en laat een kapotte regel correct lijken.

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

Een syntaxiscontrole bewijst alleen dat het bestand parseert. Inloggegevens, ACL's en de hostbeslissing worden door een echte verbinding geoefend, dus voer de clientopdracht uit vanaf het adres dat je wilt testen en kijk welke fase die weigert. Als een gekruist paar slaagt, is de effectieve hostlijst breder dan het blok suggereert, en testparm -s is het eerste dat gelezen moet worden. Als een gekruist paar om de verkeerde reden mislukt, zijn het account of de ACL de verdachte.

Sessies met smbstatus monitoren en beëindigen is een reactie na het begin van toegang, geen toegangscontrole. Een heel waargenomen adres blokkeren kan ook ongerelateerde gebruikers achter dezelfde NAT loskoppelen, en daarom hoort de beslissing in de sharedefinitie en de monitoring in het reactieproces. Houd de twee gescheiden en het ontwerp blijft eerlijk over wat het afdwingt.