User ID mapping issue with non-existing user on NFSv4 Client
Erik Logtenberg
erik at logtenberg.eu
Mon Aug 14 10:18:22 EDT 2006
Dear List,
I have a bit of a technical question, and I hope you are willing to give
it a little thought. I noticed some behaviour of libnfsidmap which I
didn't expect, perhaps you can shed some light on this:
I have two machines, a Server (Gentoo Linux 2.6.17) and a Client (Gentoo
Linux 2.6.17). The server exports an NFSv4 share to the client, and all
is working fine.
Now on the server, I have 2 users: erik (1000) and marloes (1001). On
the client, only user erik (1000) is defined. There is no user marloes
and uid 1001 doesn't exist. Now I would expect the client to map user
marloes to uid 65534 (nobody), since that is the configured default.
Instead, look what happens:
Aug 12 22:53:26 [rpc.idmapd] Client 18: (group) name
"users at logtenberg.vpn" -> id "100"
Aug 12 22:53:31 [rpc.idmapd] Client 18: (user) name
"erik at logtenberg.vpn" -> id "1000"
Aug 12 22:53:31 [rpc.idmapd] nss_getpwnam: name 'marloes' not found in
domain 'logtenberg.vpn'_
Aug 12 22:53:31 [rpc.idmapd] Client 18: (user) name
"marloes at logtenberg.vpn" -> id "1000"
You see here that it cannot find user marloes, but now instead of
mapping it to nobody, it maps it to uid 1000, which is user erik... As
you can see, this happens to be the last uid that libidmapd resolved, so
I figure that rpc.idmapd doesn't quite catch the error, but instead
re-uses a piece of memory where uid 1000 is still stored.. or perhaps
something else?
Anyway, for the end-user it looks like this:
Serverside:
drwx------ 2 erik users 17 Aug 12 22:53 erik
drwx------ 2 marloes users 6 Aug 12 21:45 marloes
Clientside:
drwx------ 2 erik users 17 Aug 13 2006 erik
drwx------ 2 erik users 6 Aug 12 2006 marloes
The server (I suppose) is however clever enough to prevent user erik
from exploiting this:
erik at bak2 ~ $ touch /mnt/test/home/marloes/test
touch: cannot touch `/mnt/test/home/marloes/test': Permission denied
I sent this email to Bruce Fields first, and he asked me for some more
details:
The Server and Client have the exact same kernel version and
userspace tools (linux-2.6.17-gentoo-r4, libnfsidmap-0.16,
nfs-utils-1.0.9, portmap-5b-r9).
The idmapd.conf (equal on both machines) contains:
-- start
[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = logtenberg.vpn
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
-- end
On both Server and Client pipefs is mounted as:
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
On both Server and Client the nobody group and user exists as:
uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)
This is consistent with the way the volume is exported:
/data/home
192.168.1.22(rw,async,wdelay,root_squash,no_subtree_check,anonuid=65534,anongid=65534)
/data
192.168.1.22(rw,wdelay,root_squash,no_subtree_check,fsid=0,anonuid=65534,anongid=65534)
On the subnet there is a DNS service (bind 9) on another server, which
hosts the logtenberg.vpn domain, which is an internal-only domain. There
is an entry for the Client (192.168.1.22) but not (yet) for the Server.
I don't suppose that's actually causing a problem since both machines
only consult their own /etc/passwd for users/uid's.
Perhaps I should add that I haven't installed or configured Kerberos
(yet?) so there is currently no security framework in place. I don't
suppose this should be a problem either.
I hope someone can confirm that I am correct in assuming the
non-existing user 'marloes' on the Client should have been mapped to
user nobody (65534), and perhaps it's possible to see wether this is a
configuration mistake on my part or a bug in the current libidmapd or
nfs-utils package?
Kind regards,
Erik Logtenberg.
More information about the NFSv4
mailing list