permissões NFSv4 no AIX

2

Eu estou tentando usar uma montagem NFSv4 em dois sistemas que não compartilham UID / GIDs. Isso é para uma migração do sistema em que o ambiente antigo usava os UID / GIDs disponíveis e agora entra em conflito com o novo ambiente. Eu dei a todos os usuários novos IDs não conflitantes no novo ambiente.

Meu problema é a montagem do NFS. Eu estou tentando usar o NFSv4 devido a ele passando IDs como strings, não como números (o que deve ajudar no mapeamento). Eu posso obter um sistema de arquivos montado no ambiente antigo, e quando eu faço um ls -l , vejo os nomes corretos em ambos os lados (então o mapeamento está funcionando).

Quando tento tocar um arquivo como um usuário (um usuário que existe em ambos os sistemas com UIDs diferentes), recebo permissão negada. O usuário é um membro do grupo apropriado em ambos os sistemas (o grupo tem diferentes GIDs em ambos os ambientes, mas o usuário é um membro adequado em ambos os lados).

Existem outras opções para corrigir meu problema (usando o NFSv3 e re-mapeando UID / GIDs), mas não quero fazer isso se puder evitá-lo.

Aqui está minha configuração e alguns testes para mostrar o que eu vejo ...

Configuração do servidor:

# chnfsdom
Current local domain: red.act.ed
# cat /etc/exports
/usr/sap/trans -vers=4,sec=sys,rw,root=172.29.4.56:172.29.4.55:172.29.4.65
# ls -ld /usr/sap/trans/data
drwxrwxr-x    2 d01adm   sapsys       118784 Apr 23 08:25 /usr/sap/trans/data
# ls -nld /usr/sap/trans/data
drwxrwxr-x    2 300      300          118784 Apr 23 08:25 /usr/sap/trans/data

Configuração do cliente:

# chnfsdom
Current local domain: red.act.ed
# mount | grep trans
devbox   /usr/sap/trans   /usr/sap/trans   nfs4   Apr 23 09:01 vers=4
qabox:/ # ls -ld /usr/sap/trans/data
drwxrwxr-x    2 d01adm   sapsys       118784 Apr 23 09:25 /usr/sap/trans/data
qabox:/ # ls -nld /usr/sap/trans/data
drwxrwxr-x    2 8        14           118784 Apr 23 09:25 /usr/sap/trans/data

Com base nessas informações, parece que a tradução de UID / GID está funcionando corretamente. Aqui está o atrito (na caixa do cliente) ...

qabox:q01adm> pwd
/usr/sap/trans
qabox:q01adm> ls -ld .
drwxrwxr-x   14 d01adm   sapsys         4096 Apr 23 09:56 .
qabox:q01adm> id
uid=12(q01adm) gid=14(sapsys) groups=0(system),7(security),4294967294(nobody),15(oper),16(dba)
qabox:q01adm> touch file
touch: 0652-046 Cannot create file.

Veja o que posso fazer com o root na mesma caixa do cliente:

qabox:/usr/sap/trans # pwd
/usr/sap/trans
qabox:/usr/sap/trans # id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp),14(sapsys)
qabox:/usr/sap/trans # touch file
qabox:/usr/sap/trans # chown q01adm:sapsys file
qabox:/usr/sap/trans # ls -l file
-rw-r--r--    1 q01adm   sapsys            0 Apr 23 09:59 file
qabox:/usr/sap/trans # ls -nl file
-rw-r--r--    1 12       14                0 Apr 23 09:59 file

E na caixa do servidor, vejo isto:

# ls -l /usr/sap/trans/file
-rw-r--r--    1 q01adm   sapsys            0 Apr 23 08:59 /usr/sap/trans/file
# ls -nl /usr/sap/trans/file
-rw-r--r--    1 302      300               0 Apr 23 08:59 /usr/sap/trans/file

Então, de tudo que eu posso ver ... a tradução de UID / GID está funcionando corretamente, eu não consigo escrever arquivos como um usuário não-root no cliente.

    
por baumgart 23.04.2014 / 14:07

1 resposta

2

De acordo com meu conhecimento limitado, o mapeamento de ID do NFSv4 aplica-se somente aos resultados stat () e outras informações enviadas pelo próprio NFS, ou seja, aos proprietários de arquivos enviados por chown , retornados por ls ou stat . etc.

No entanto, a autenticação é tratada por um nível inferior - SunRPC - que ainda usa seu UID numérico no protocolo AUTH_UNIX padrão. Então, se você é o usuário # 12 localmente, é o que o servidor receberá também.

Para evitar isso, você precisaria de um mecanismo de autenticação que suporte nomes de usuários; Kerberos (AUTH_GSS) pode ser a única escolha aqui.

    
por 23.04.2014 / 18:14