User ID mapping issue with non-existing user on NFSv4 Client
Kevin Coffman
kwc at citi.umich.edu
Mon Aug 14 13:14:54 EDT 2006
Hi Erik,
Thanks for the report. This looks like it is a bug in libnfsidmap.
I'm working on a fix.
On 8/14/06, Erik Logtenberg <erik at logtenberg.eu> wrote:
> 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.
> _______________________________________________
> NFSv4 mailing list
> NFSv4 at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
>
>
More information about the NFSv4
mailing list