Restringindo clientes NFS a determinados endereços IP bloqueia _todos_ endereços

Question

Estou tendo problemas para obter um servidor Solaris 11.0 para restringir o acesso a um compartilhamento NFS em um único sistema cliente.

Eu tenho aproximadamente o seguinte valor para a propriedade share de um sistema de arquivos tank/mail ZFS:

name=mail,path=/tank/mail,prot=nfs,none=*,[email protected],sec=sys

Não consigo montar o compartilhamento no cliente (executando o Solaris 11.3) em 10.0.23.43. Eu tento assim:

mount -F nfs keisha:/tank/mail /tmp/mnt

e obtenha o seguinte erro:

nfs mount: mount: /tmp/mnt: Permission denied

Se eu remover none=* , o cliente será montado corretamente. No entanto, entendo que isso permitirá o acesso a clientes em qualquer endereço, o que eu quero evitar (e sim, estou ciente de que pode ser possível falsificar o endereço, mas preferir para adicionar o que eu puder.)

Eu tentei reverter a ordem de none e rw , e isso não muda nada. Eu tentei [email protected]/32 e isso não funciona.

Eu tentei abri-lo para toda a sub-rede com [email protected]/16 e mesmo que não funciona. Também verifiquei duas vezes se tenho o endereço do cliente correto. O cliente não pode usar o IPv6 para acessar o servidor, pois a entrada DNS do servidor é apenas IPv4 e estou acessando pelo nome.

Por que restringir os endereços dos clientes impede o acesso mesmo de um cliente em um endereço explicitamente permitido ? Como faço para corrigir isso?

    

Answer 1

Parece que o ridgy respondeu à sua pergunta, se for compartilhado com apenas um host. Se você tiver vários, usando um ponto-e-vírgula, ou criando um netgroup poderia ser usado.

Se você precisar / quiser um bloqueio adicional, você pode procurar usar o ipfilters ou o Solaris Firewall derivado do OpenBSD PF (pkg: / network / firewall).

    

Answer 2

O comentário de ridgy sugeriu a resposta. O que foi necessário foi remover none , deixando:

name=mail,path=/tank/mail,prot=nfs,[email protected],sec=sys

(É possível omitir o @ , mas a documentação exige, então achei melhor deixá-lo, caso a interpretação se torne mais rigorosa no futuro.)

Este é um caso de documentação deficiente. A página man states (ênfase minha):

none
Access is disallowed to all clients. The ro or rw options can override none.

none=access_list
Access is not allowed to any client that matches the access list. The exception is when the access list is an asterisk (*), in which case ro or rw can override none.

Isso não só indica explicitamente que meu cliente em 10.0.23.43 deveria ter obtido acesso mesmo com none (o que não aconteceu) também implica que você precisa none para evitar que clientes não listados em rw recebam pelo menos algum tipo de acesso, porque senão, por que a exceção de substituição para none=* teria (supostamente) sido implementada? Seria redundante !

Eu não tinha nenhum outro cliente NFS à mão para testar, então eu mudei o número IP do meu cliente e confirmei que, de fato, none não é necessário para clientes que não são de outra forma listado para ter acesso negado. Só para ter certeza, adicionei ro como teste e meu cliente em um endereço diferente poderia ler, mas não escrever.

Embora esta parece ser a solução, eu não estou feliz com isso, porque a documentação implica que o que estou fazendo é deixá-lo bem aberto, e de fato eu poderia estar fazendo exatamente isso em uma versão futura que se corrige obedecer as intenções implícitas na documentação. (Pelo menos eu tenho firewalls externos.)