permissão NFS4 negada quando o ID do usuário não corresponde (mesmo que o idmap esteja funcionando)

Question

Eu tenho a configuração do NFS4 com o idmapd funcionando corretamente. ls -l do cliente mostra os nomes de usuário corretos, mesmo que os IDs do usuário sejam diferentes entre as máquinas.

No entanto, quando os IDs de usuário não coincidem, recebo erros de 'permissão negada' ao tentar acessar arquivos, mesmo que ls -l mostre o nome de usuário correto. Quando os IDs dos usuários coincidem por coincidência, tudo funciona bem.

sudo sysctl -w sunrpc.nfsd_debug=1023 fornece a seguinte saída no syslog do servidor para o acesso a arquivo com falha:

nfsd_dispatch: vers 4 proc 1
nfsv4 compound op #1/3: 22 (OP_PUTFH)
nfsd: fh_verify(28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba)
nfsv4 compound op ffff88003d0f5078 opcnt 3 #1: 22: status 0
nfsv4 compound op #2/3: 3 (OP_ACCESS)
nfsd: fh_verify(28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba)
nfsd: fh_verify - just checking
nfsv4 compound op ffff88003d0f5078 opcnt 3 #2: 3: status 0
nfsv4 compound op #3/3: 9 (OP_GETATTR)
nfsd: fh_verify(28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba)
nfsd: fh_verify - just checking
nfsv4 compound op ffff88003d0f5078 opcnt 3 #3: 9: status 0
nfsv4 compound returned 0
nfsd_dispatch: vers 4 proc 1
nfsv4 compound op #1/7: 22 (OP_PUTFH)
nfsd: fh_verify(28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba)
nfsv4 compound op ffff88003d0f5078 opcnt 7 #1: 22: status 0
nfsv4 compound op #2/7: 32 (OP_SAVEFH)
nfsv4 compound op ffff88003d0f5078 opcnt 7 #2: 32: status 0
nfsv4 compound op #3/7: 18 (OP_OPEN)
NFSD: nfsd4_open filename dom_file op_stateowner (null)
renewing client (clientid 4f96587d/0000000e)
nfsd: nfsd_lookup(fh 28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba, dom_file)
nfsd: fh_verify(28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba)
nfsd: fh_verify - just checking
nfsd: fh_lock(28: 00070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba) locked = 0 
nfsd: fh_compose(exp 08:01/22806529 srv/dom_file, ino=22809724)
nfsd: fh_verify(36: 01070001 015c0001 00000000 9853d400 2a4892a5 4918a0ba)
nfsd: fh_verify - just checking
fh_verify: srv/dom_file permission failure, acc=804, error=13
nfsv4 compound op ffff88003d0f5078 opcnt 7 #3: 18: status 13
nfsv4 compound returned 13

Isso é útil para alguém? Qualquer dica para depurar isso seria muito apreciada.

Server kernel: 2.6.32-40-server (Ubuntu 10.04)
Client kernel: 3.2.0-27-generic (Ubuntu 12.04)

O mesmo problema com meu novo servidor executando 3.2.0-27-generic (Ubuntu 12.04) .

Obrigado.

    

Answer 1

O NFSv4 usa os principais da cadeia utf8 entre o cliente e o servidor. Como resultado, basta usar os mesmos nomes de usuário e domínio nfs4 no cliente e no servidor. Os uids podem ser diferentes. MAS .... Se você usar AUTH_SYS (mount com sec = sys, que é o padrão) suas requisições RPC em vez de kerberos principal usarão uid e gids do host do cliente. Nesse caso, se os uids no cliente e no servidor forem diferentes, você terá acesso negado. No caso de RPCGSS_SEC, o seu kerberos principal é enviado e no servidor usará o mesmo idmapd para mapeá-lo para uid e gids locais. ls -l funciona como esperado, pois usa o idmapd para mapear os IDs do proprietário e do grupo de arquivos para os principais que, posteriormente, enviam para o cliente.