Re: [PATCH] libnfsidmap: respect Nobody-User/Nobody-Group

[Christian Seiler <christian@iwakd.de>]

Hi,

Am 2014-08-13 18:45, schrieb Steve Dickson:
> On 06/03/2014 07:17 AM, Christian Seiler wrote:
>> Previous behavior of libnfsidmap was to do a name lookup of
>> nobody@DEFAULTDOMAIN (for both user and group), which does not match
>> the behavior of rpc.idmapd.
>>
>> This patch makes libnfsidmap respect Nobody-User/Nobody-Group for
>> lookups, thus making the nfsidmap utility properly handle the case 
>> if
>> nobody@DEFAULTDOMAIN does not directly map to any user/group on the
>> system.
>>
>> Signed-off-by: Christian Seiler <christian@iwakd.de>
> Wow... This one fell of the radar... sorry about that!

No problem. To be honest, I completely forgot about this patch
myself, because I wrote this patch when I tried to switch from
idmapd to nfsidmap, but after I had some problems with that, I
kind of switched back to idmapd, and then kind of put the whole
thing to the back of my mind.

But perhaps you can give me a couple of pointers on how to
best debug the issue I had with nfsidmap:

  - nsswitch translation for idmapping, nss_ldapd
  - nfsv4 sec=krb5 mount (mounted via autofs)
  - no krb5 ticket: ls doesn't even work (permission denied)
    (this is expected, not a bug)
  - with krb5 ticket: ls -l shows correct directory contents,
    with correct user/group ownership (translation nfs4 ->
    uid/gid via nfsidmap and then uid/gid -> local names via
    getpwnam works)
  - accessing files owned by myself but that are not group/other
    readable doesn't work (permission denied)
  - writing to files / directories on which I have write
    permission (but no other write permission) doesn't work
  - nfsv4 sec=sys mounts don't have this problem

To me this appears to be a problem that while uids/gids are
correctly mapped when getting data from the server, they are
not mapped properly when sending requests to the server, so
that it always falls back to nobody, therefore giving me
insufficient permissions.

The problem doesn't occur with rpc.idmapd (and disabled
nfsidmap).

My question would be whether there is an easy way to debug this?
I tried to have a look at the kernel nfs4 client code / the
interaction with idmap, but I just don't know enough about that
area of the kernel to really see through the logic.

> Committed!

Thanks!

Regards,
Christian