Início / server / Perguntas / 715066
Accepted
cornuz
Asked: 2015-08-19 09:27:52 +0800 CST

Mapeamento de usuário incorreto em diretórios iniciais NFSv4 kerberizados montados automaticamente

  • 772

Breve descrição do problema

Esta questão é sobre o mapeamento de id no NFSv4 dando errado.

Servidor NFS: um Synology DS, com DSM 5.2.

Cliente: Uma máquina FC22 normal, que monta automaticamente como /home uma das pastas exportadas acima.

Ambas as máquinas são clientes inscritos de um domínio freeIPA, portanto, usando o servidor freeIPA como servidor DNS e LDAP.

Quando um usuário LDAP efetua login no cliente, ele encontra a pasta montada. Então a montaria funciona. No entanto, as propriedades dos arquivos são mapeadas como nobody:nobody. Sei que esse "problema de ninguém" não é novo, mas nenhuma das soluções que encontrei até agora resolve o problema.

Login do usuário LDAP e toque no arquivo

$ ssh ldapuser1@client1
ldapuser1@client1's password: 

-bash-4.3$ id
uid=1172000004(ldapuser1) gid=1172000004(ldapuser1) groups=1172000004(ldapuser1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

ldapuser1pode logar corretamente e tem uid 1172000004.

-bash-4.3$ pwd
/home/ldapuser1

-bash-4.3$ ls -lan
total 8
drwxrwxrwx. 2 1172000004 1172000004 4096 18 aug 17:34 .
drwxr-xr-x. 3          0          0    0 18 aug 18:33 ..

O usuário LDAP aterrissa corretamente em seu diretório home, previamente criado e atribuído a ele. Mas qualquer novo arquivo recebe a propriedade errada:

-bash-4.3$ touch a

-bash-4.3$ ls -lan
total 8
drwxrwxrwx. 2 1172000004 1172000004 4096 18 aug 18:41 .
drwxr-xr-x. 3          0          0    0 18 aug 18:33 ..
-rwxrwxrwx. 1         99        100    0 18 aug 18:42 a

Observe que 99:100 está guest:usersno servidor. O arquivo idmapd.confno servidor diz para mapear nobody:nobodypara guest:users.

Configuração do servidor

$ exportfs -v   
/volume1/shared_homes xxx.xxx.0.0/24(rw,async,no_root_squash,no_subtree_check,insecure_locks,anonuid=1025,anongid=100,sec=krb5,rw,no_root_squash,no_all_squash)


$ klist -k /etc/nfs/krb5.keytab 
Keytab name: FILE:/etc/nfs/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   5 nfs/[email protected]
   5 nfs/[email protected]
   5 nfs/[email protected]
   5 nfs/[email protected]

$ cat /etc/idmapd.conf 
[General]
Domain=hq.example.com
Verbosity=10
[Mapping]
Nobody-User=guest
Nobody-Group=users
[Translation]
Method=nsswitch
GSS-Methods=static,synomap
[Static]

$ cat /etc/nsswitch.conf
passwd:     files ldap winbind
shadow:     files ldap winbind
group:      files ldap winbind
osts:      files dns wins
bootparams: files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files
netgroup:   files
publickey:  nisplus
automount:  files
aliases:    files

Configuração do cliente

$ automount -s
Mount point: /home
source(s):
  instance type(s): sss 
  map: auto.home
  * | -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 nfs-server.hq.example.com:/volume1/shared_homes/&

$ df
nfs-server.hq.example.com:/volume1/shared_homes/ldapuser1 11609721368 2208608120 9400994464  20% /home/ldapuser1

$ cat /etc/idmapd.conf
[General]
Domain=hq.example.com


$ cat /etc/nsswitch.conf
passwd:     files sss
shadow:     files sss
group:      files sss
hosts:      files dns myhostname
bootparams: nisplus [NOTFOUND=return] files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss
netgroup:   files sss
publickey:  nisplus
automount:  files sss
aliases:    files nisplus
sudoers: files sss

$ cat /etc/sysconfig/nfs | egrep -v "^#"
RPCNFSDARGS=""
RPCMOUNTDOPTS=""
STATDARG=""
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
RPCGSSDARGS="-vvv"
GSS_USE_PROXY="yes"
RPCSVCGSSDARGS="-vvv"
BLKMAPDARGS=""
SECURE_NFS=yes

Servidor de LOGS

Aug 18 18:50:59 nfs-server idmapd[14622]: nfsdcb: authbuf=gss/krb5 authtype=user
Aug 18 18:50:59 nfs-server idmapd[14622]: nfs4_uid_to_name: calling nsswitch->uid_to_name
Aug 18 18:50:59 nfs-server idmapd[14622]: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
Aug 18 18:50:59 nfs-server idmapd[14622]: nfs4_uid_to_name: final return value is 0
Aug 18 18:50:59 nfs-server idmapd[14622]: Server : (user) id "1173000004" -> name "[email protected]"
Aug 18 18:50:59 nfs-server idmapd[14622]: nfsdcb: authbuf=gss/krb5 authtype=group
Aug 18 18:50:59 nfs-server idmapd[14622]: nfs4_gid_to_name: calling nsswitch->gid_to_name
Aug 18 18:51:00 nfs-server idmapd[14622]: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
Aug 18 18:51:00 nfs-server idmapd[14622]: nfs4_gid_to_name: final return value is 0
Aug 18 18:51:00 nfs-server idmapd[14622]: Server : (group) id "1173000004" -> name "[email protected]"

Observe que os mapeamentos parecem ser solicitados para o usuário/domínio correto. No log, no entanto, também encontrei muitas referências a mapeamentos de [email protected]e [email protected].

Cliente LOGS

aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: key: 0x274d13a5 type: uid value: [email protected] timeout 600
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: nfs4_name_to_uid: calling nsswitch->name_to_uid
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: nss_getpwnam: name '[email protected]' domain 'hq.example.com': resulting localname 'ldapuser1'
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: nfs4_name_to_uid: final return value is 0
aug 18 18:50:59 client1.hq.example.com nfsidmap[2120]: key: 0x3e28949 type: gid value: [email protected] timeout 600
aug 18 18:50:59 client1.hq.example.com nfsidmap[2120]: nfs4_name_to_gid: calling nsswitch->name_to_gid
aug 18 18:50:59 client1.hq.example.com nfsidmap[2120]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0
aug 18 18:50:59 client1.hq.example.com nfsidmap[2120]: nfs4_name_to_gid: final return value is 0

Observações e perguntas

  • A causa mais comum de mapeamento incorreto nesses casos parece ser a Domainconfiguração ausente ou não consistente em idmapd.confambos os lados. Aqui está corretamente definido em ambos os lados
  • Funciona se eu usar mapeamentos estáticos, ou seja, 1) criar local ldapuser1no servidor 2) adicionar uma entrada em [Static] em idmapd.conf, que diz [email protected]=ldapuser1. No entanto, este não é o objetivo.
  • O servidor Synology obviamente não é Fedora/RedHat, então não é o companheiro freeIPA perfeito. Em particular, sente falta SSSD. Ainda assim, acho que deve funcionar.

Estou completamente preso neste ponto. Não sei nem onde pedir ajuda. O suporte da Synology afirma que isso deve funcionar. De acordo com os desenvolvedores do freeIPA, isso está fora do tópico, porque não é específico do freeIPA, mas "apenas" problemas de NFS & co. Isso é discutível, pois a maneira como todas essas tecnologias são conectadas e usadas é específica do freeIPA.

De qualquer forma, não sei mais o que olhar. É por isso que pergunto aqui esperando que alguém possa me fazer dar pelo menos mais um passo à frente. Qualquer palpite é mais do que bem-vindo!

ldap

1 respostas

  1. Best Answer

    Depois de uma sessão com o suporte da Synology, finalmente entendi que isso não pode funcionar no momento, devido a uma limitação do DSM 5.2.

    O problema é que o DSM assume que o servidor LDAP usa o esquema UMich , que é específico do NFS, portanto, procura atributos quando GSSAuthNameuma solicitação GSS chega. krbPrincipalNameacessível.

    Não encontrando GSSAuthName, o DSM mapeia cada solicitação para nobody.

    Fiz uma solicitação de recurso à Synology para usar o SSSD para lidar com o mapeamento de id corretamente.

    Até então, eu recorria a sec=sys. Nota: certifique-se de que a opção "Enable UID/GID shifting" ni Synology LDAP configuration está desmarcada!

    • 1

relate perguntas