Re: Kerberos-secured NFSv4: nss_getpwnam: name '8' does not map into domain
Hi,
Am 2015-07-08 15:34, schrieb Jonas Meurer:
I've another annoying issue with my new Kerberos-secured NFSv4 setup.
Sometimes when Exim4 writes to the mounted NFS share, it fails to set
owner and permissions on the written file. Exim4 runs as local user
Debian-exim:Debian-exim but tries to set owner of created files on
the NFS share to 'mail:mail'. Both the local user Debian-exim and
the local user mail are authenticated against the Kerberos server and
principals 'Debian-exim@DOMAIN.ORG' as well as 'mail@DOMAIN.ORG' do
exist.
Obviously, not time Exim4 creates a file and sets owner on the NFS
share, the error is produced. Most of the time, this just works and
new files are owned by 'mail:mail'. But sometimes, it fails. In
these cases, Exim4 gives the following error:
In the meantime, I did some further debugging. I still have no clue
what triggers the error. It happens serveral times every hour, but
I didn't find a pattern yet. Interestingly, the error vanishs by
itself after a few minutes.
Below's some debugging output of rpc.idmapd on the Kerberos-/NFS-
Server.
This is from an 'invalid argument' error triggered by a chown
operation by Exim4 (to mail:mail) on the NFS client:
Jul 10 10:46:59 nfs1 rpc.idmapd[4946]: nfsdcb: authbuf=gss/krb5i
authtype=user
Jul 10 10:46:59 nfs1 rpc.idmapd[4946]: nfs4_name_to_uid: calling
nsswitch->name_to_uid
Jul 10 10:46:59 nfs1 rpc.idmapd[4946]: nss_getpwnam: name '8' domain
'freesources.org': resulting localname '(null)'
Jul 10 10:46:59 nfs1 rpc.idmapd[4946]: nss_getpwnam: name '8' does not
map into domain 'freesources.org'
Jul 10 10:46:59 nfs1 rpc.idmapd[4946]: nfs4_name_to_uid:
nsswitch->name_to_uid returned -22
Jul 10 10:46:59 nfs1 rpc.idmapd[4946]: nfs4_name_to_uid: final return
value is -22
Jul 10 10:46:59 nfs1 rpc.idmapd[4946]: Server : (user) name "8" -> id
"65534"
This is from an 'invalid argument' error triggered by a manual
'chown mail:mail ...' by root user on the NFS client:
Jul 10 10:49:12 nfs1 rpc.idmapd[4946]: nfsdcb: authbuf=gss/krb5i
authtype=user
Jul 10 10:49:12 nfs1 rpc.idmapd[4946]: nfs4_uid_to_name: calling
nsswitch->uid_to_name
Jul 10 10:49:12 nfs1 rpc.idmapd[4946]: nfs4_uid_to_name:
nsswitch->uid_to_name returned 0
Jul 10 10:49:12 nfs1 rpc.idmapd[4946]: nfs4_uid_to_name: final return
value is 0
Jul 10 10:49:12 nfs1 rpc.idmapd[4946]: Server : (user) id "8" -> name
"mail@freesources.org"
Jul 10 10:49:12 nfs1 rpc.idmapd[4946]: nfsdcb: authbuf=gss/krb5i
authtype=group
Jul 10 10:49:12 nfs1 rpc.idmapd[4946]: nfs4_gid_to_name: calling
nsswitch->gid_to_name
Jul 10 10:49:12 nfs1 rpc.idmapd[4946]: nfs4_gid_to_name:
nsswitch->gid_to_name returned 0
Jul 10 10:49:12 nfs1 rpc.idmapd[4946]: nfs4_gid_to_name: final return
value is 0
Jul 10 10:49:12 nfs1 rpc.idmapd[4946]: Server : (group) id "8" -> name
"mail@freesources.org"
And this is from a successfull 'chown mail:mail ...' by root user
on the NFS client just after it works again:
Jul 10 10:50:34 nfs1 rpc.idmapd[4946]: nfsdcb: authbuf=gss/krb5i
authtype=user
Jul 10 10:50:34 nfs1 rpc.idmapd[4946]: nfs4_name_to_uid: calling
nsswitch->name_to_uid
Jul 10 10:50:34 nfs1 rpc.idmapd[4946]: nss_getpwnam: name
'mail@freesources.org' domain 'freesources.org': resulting localname
'mail'
Jul 10 10:50:34 nfs1 rpc.idmapd[4946]: nfs4_name_to_uid:
nsswitch->name_to_uid returned 0
Jul 10 10:50:34 nfs1 rpc.idmapd[4946]: nfs4_name_to_uid: final return
value is 0
Jul 10 10:50:34 nfs1 rpc.idmapd[4946]: Server : (user) name
"mail@freesources.org" -> id "8"
Jul 10 10:50:34 nfs1 rpc.idmapd[4946]: nfsdcb: authbuf=gss/krb5i
authtype=group
Jul 10 10:50:34 nfs1 rpc.idmapd[4946]: nfs4_name_to_gid: calling
nsswitch->name_to_gid
Jul 10 10:50:34 nfs1 rpc.idmapd[4946]: nfs4_name_to_gid:
nsswitch->name_to_gid returned 0
Jul 10 10:50:34 nfs1 rpc.idmapd[4946]: nfs4_name_to_gid: final return
value is 0
Jul 10 10:50:34 nfs1 rpc.idmapd[4946]: Server : (group) name
"mail@freesources.org" -> id "8"
1234567890123456789012345678901234567890123456789012345678901234567890
Probably this is related to Kerberos authentication tickets? I
authenticate users Debian-exim, dovecot and mail from client to the
Kerberos server with k5start by using the following k5start syntax:
start-stop-daemon --start --quiet --exec /usr/bin/k5start --pidfile \
/var/run/k5start-${USR}.pid -- -u ${USR} -o ${USR} -p \
/var/run/k5start-${USR}.pid -k /tmp/krb5cc_$(id -u $USR) -b \
-f /etc/krb5.keytab -L -K 15
Sometimes it seems to help to restart k5start. Immediately afterwards,
the owner change works again. But I already discovered the opposite,
and a restart of k5start didn't change anything.
I'm a bit lost on debugging the problem. Unfortunately this whole
Kerberos world is rather new to me. If you have any hints about
how to proceed, that would be awesome :)
Cheers,
jonas
2015-07-08 12:56:43 ... defer (22): Invalid argument: while setting
perms on maildir tmp/1742360537.H643669P4542.clt.domain.org
At the same time, the NFS/Kerberos-Server logs the following:
Jul 8 12:59:30 nfs1 rpc.idmapd[4353]: nss_getpwnam: name '8' does not
map into domain 'domain.org'
Even more weird, after the described error happens, owner changes
don't work at all anymore for some time. Something like five minutes
later, everything works as expected again.
After searching the web, my first guess is that this is due to Exim4
trying to set owner of the created file to '8:8' instead of using
'mail:mail'. It seems like using UIDs isn't supported on
Kerberos-secured NFSv4 shares. Idmapd on the NFS/Kerberos server
is unable to map the user name '8' to a Kerberos principal.
But more testing reveiled that even a chown to '8:8' works on the
NFS share. So using UID instead of username doesn't seem to be the
problem here.
Do you have suggestions about what's the problem here or how to go
on with debugging?
Cheers,
jonas
Reply to: