Restrinxir un recurso compartido de Samba a un usuario e un enderezo VPN

Neste deseño confúndense dous permisos distintos: quen pode usar un directorio e que enderezos poden conectarse sequera. Escribir unha lista de contas xunto a unha lista de orixes parece un emparellamento, pero Samba avalía as dúas listas como predicados independentes. Admítese a calquera que satisfaga ambas, o que é unha regra máis ampla do que a maioría dos administradores pretende. A solución é ou outro deseño do recurso ou unha capa de política que poida expresar o par.

O mito: dúas listas fan unha regra

A referencia de smb.conf define valid users e hosts allow como dous parámetros non relacionados, e é ao pór ambos nun mesmo recurso onde comeza a confusión. Pon valid users = mira, tomas e hosts allow = 10.77.0.21, 10.77.0.22 e admítense catro combinacións: Mira desde calquera dos dous enderezos e Tomás desde calquera dos dous enderezos. Nada na configuración ata o primeiro nome ao primeiro enderezo, e a orde en que aparecen os nomes non ten significado ningún. Reordenalos, engadir unha segunda liña hosts allow ou pór un nome por liña non cambia nada. O resultado é o produto de dúas listas, non unha correspondencia entre elas.

O que a maioría quere en realidade é máis estreito: Mira só desde un enderezo e Tomás só desde outro. Unha soa definición de recurso non ten sintaxe para esa vinculación, e ningunha orde enxeñosa a crea. Esa é unha forma de política que Samba non expresa dentro dun só recurso, e aí sobrevive o mito.

Que avalía Samba e en que orde

As etapas seguen unha orde fixa, e equivocar a orde produce o diagnóstico equivocado. Un cliente abre unha conexión; execútase unha comprobación global de host se hai unha configurada; a configuración da sesión autentica a conta; despois o cliente conéctase a un recurso, onde se aplican a súa propia lista de hosts, valid users e o axuste de só lectura; e só cando se abre un ficheiro deciden os permisos do sistema de ficheiros da identidade autenticada. Cada etapa pode rexeitar a petición por si soa, e pasar unha non di nada da seguinte. A consecuencia importante é que a conta xa se coñece cando se avalía a lista de hosts do recurso, e a lista de hosts segue sen ter forma de nomear esa conta.

Por iso un recurso non pode atar un usuario a un enderezo: hosts allow e valid users son predicados separados que se aplican na mesma etapa de conexión da árbore, e cada un responde á súa propia pregunta. O predicado de host nunca toma o nome da conta como entrada, así que non se pode escribir por usuario. Só un segundo recurso ou unha capa de política fóra de Samba poden expresar o par.

Os valores globais importan por como se herdan. Un recurso que omite hosts allow herda o valor global, e un recurso que establece o seu usa ese valor no canto do global, non ademais del. Así, unha lista global ampla amplía os recursos que nunca definen o parámetro e non fai nada a un recurso que define o seu. Executa testparm -s e le os valores por recurso que imprime, porque esa saída é a política efectiva e o ficheiro do disco non o é.

Restrinxir un recurso tampouco fai nada polo resto do servidor. Os demais recursos, as colas de impresión e a conexión IPC manteñen as súas propias regras, así que un deseño que se apoia na lista de enderezos dun só recurso protexe un camiño e non o host.

Dous nomes de recurso sobre un directorio

Cando o mesmo directorio ten que ser accesible por dúas persoas desde dous enderezos, expono dúas veces con nomes distintos. Cada bloque leva unha conta e unha orixe, o que converte o par en algo que a configuración pode impor. O custo é que cada persoa usa un nome de recurso distinto para chegar aos mesmos ficheiros, e iso ten que ser un cambio deliberado no lado do cliente.

[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

Unha porta de recurso non é un permiso do sistema de ficheiros. Ambas as identidades seguen necesitando acceso ao directorio a través da ACL subxacente, e o axuste de só lectura é unha segunda capa e non a única. Concede acceso de escritura só se o fluxo de traballo o esixe, e despois comproba que os ficheiros creados por unha identidade seguen sendo utilizables pola outra.

Ambos os bloques apuntan a unha soa ruta, así que un cambio no directorio afecta os dous recursos. Normalmente ese é o obxectivo, pero tamén significa que un erro de permisos é visible para os dous usuarios á vez.

Que pode demostrar o enderezo de orixe

O enderezo que ve Samba é o enderezo que chegou ao servidor, non o que o cliente cre ter. Unha pasarela VPN que traduce cada cliente a un só enderezo de orixe elimina a distinción: todos os clientes chegan como o mesmo host e a lista de orixes xa non pode distinguiros. Unha asignación estable por cliente e unha pasarela que preserve a orixe son requisitos previos para usar enderezos como política. Sen ambas, a restrición mide a pasarela e non o usuario.

Aínda así, un enderezo non é un dispositivo. Dous portátiles detrás dun enderezo de túnel, unha concesión reasignada e unha estación de traballo compartida desminten a suposición de que unha orixe identifica unha persoa. Trata a restrición como ámbito de rede e mantén as contas SMB autenticadas como a capa de identidade, cunha credencial de dispositivo como un certificado se necesitas autorización de dispositivo.

Eso explica tamén por que o deseño pecha recursos e non o servidor. Un par rexeitado aínda pode abrir unha sesión, chegar a outro recurso ou listar o servidor, o que é un resultado distinto dun fallo de autenticación ao conectar. Se o requisito é o rexeitamento antes da autenticación, os parámetros de recurso de Samba son a ferramenta equivocada.

Demostrao con pares cruzados

Valida a configuración e despois proba as catro combinacións con conexións novas en lugar dunha sesión reutilizada. O par previsto debería chegar ao directorio, e ambos os pares cruzados deberían fallar. Unha sesión en caché dunha proba anterior responderá encantada pola combinación equivocada e fará que unha regra rota pareza correcta.

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

Unha comprobación de sintaxe só demostra que o ficheiro se analiza. As credenciais, as ACL e a decisión de host exércense cunha conexión real, así que executa o comando do cliente desde o enderezo que queres probar e observa que etapa o rexeita. Se un par cruzado ten éxito, a lista efectiva de hosts é máis ampla do que suxire o bloque, e testparm -s é o primeiro que hai que ler. Se un par cruzado falla polo motivo equivocado, a conta ou a ACL son os sospeitosos.

Monitorizar sesións con smbstatus e matalas é unha acción de resposta posterior ao inicio do acceso, non un control de admisión. Bloquear todo un enderezo observado tamén pode desconectar usuarios non relacionados detrás do mesmo NAT, e por iso a decisión pertence á definición do recurso e a monitorización ao proceso de resposta. Mantén as dúas cousas separadas e o deseño seguirá sendo honesto sobre o que impón.