Possible issue with rpc.idmapd and NFSv4.

[J. Bruce Fields]

On Wed, Dec 12, 2007 at 04:26:52PM -0500, Nathan Patwardhan wrote:
> It appears that we have an issue with large Unix groups, such that a
> group that's greater than 128 characters (group name + gid + group
> members) causes rpc.idmapd to treat the group as 'nobody' *for all
> users who are a member of this long group*.  This has obvious and bad
> consequences since users are just not mapped to the right groups.  :-)

There's a 128 character limit on the *name* of any user or group that
appears to be baked into the rpc.idmapd interfaces.  But that's
obviously not what you're hitting.

> Anyhow, consider the following:
> 
>   root# mount
>   /dev/mapper/system-root on / type ext3 (rw)
>   proc on /proc type proc (rw)
> 
>   ... etc ...
> 
>   rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
>   my.netapp.domain:/vol/users on /users type nfs4
> (rw,nosuid,nodev,sec=krb5,proto=tcp,addr=1.2.3.4)
> 
>   root# getent group unixadm
>   unixadm:x:gid-here:user1,user2,user3,user4
> 
>   root# cd /users
>   root# ls -al
>   drwxr-xr-x  6 root     root    4096 Dec 12 16:32 .
>   drwxr-xr-x 28 root     root    4096 Dec 12 20:03 ..
>   drwxrwxrwx 10 root     root    4096 Dec 12 20:00 .snapshot
>   drwxr-xr-x  2 me       unixadm 4096 Dec 12 20:54 me
> 
> That looks fine.  Unfortunately, 'me' is a member of 'staff' by
> default, so its permissions default to nobody when I chgrp to 'staff':
> 
>   root# chgrp -R staff me
>   root# ls -al
>   drwxr-xr-x  6 root     root    4096 Dec 12 16:32 .
>   drwxr-xr-x 28 root     root    4096 Dec 12 20:03 ..
>   drwxrwxrwx 10 root     root    4096 Dec 12 20:00 .snapshot
>   drwxr-xr-x  2 me       nobody  4096 Dec 12 20:54 me
> 
> Note again that 'staff' is a very large group:
> 
>   root# getent group staff
>   staff:x:600:user1,user2, ... user400
>   root# getent group staff | wc -c
>   4916
> 
> Basically, I'm able to chgrp to groups with lengths under (I suspect)
> 128 characters.

It may indeed be having a problem with groups of lots of members, but
that 128 character limit looks like a red herring.

> Also, I've confirmed that idmapd isn't handling the mapping correctly
> by running it as 'rpc.idmapd -f -vvvv'. This has told me that mapping
> works for smaller groups by larger groups appear to default to nobody.
> 
> Since we're using nfs-utils-1.0.7, I took at look at the
> nfs-utils-1.1.1 source and it looks like there might be a 128
> character limit in nfs_idmap.h and idmapd.c sets the group to nobody
> if nfs4_gid_to_name(...) returns non-zero.
> 
> Am I on the right track here?  Has anybody else noticed this problem?
> Are there available patches?  Should I try to write my own patch?
> 
> Any information would be very helpful.  This group issue is a
> show-stopper for us unfortunately.  :-(

What does your /etc/idmap.conf look like?

So you've determined that nfs4_gid_to_name is returning non-zero when
given 600 as the gid?  Then the bug is probably in libnfsidmap.

What version of libnfsidmap are you using?

--b.