Real utility of idmapd

[J. Bruce Fields]

On Tue, Mar 20, 2007 at 03:57:23PM +0100, Guillaume Rousse wrote:
> BTW, I know what ACLs are, but not what are GETATTR/SETATTR owner and
> owner_group, sorry :(

When you chown/chgrp a file, NFSv4 does a SETATTR op which sets the
owner and/or owner_group attributes.

When you stat a file, NFSv4 does a GETATTR op for the owner and
owner_group attributes (among others).

> File created on client appears to be owned by the client uid on the
> server, which lead to my initial claim. If ACLs are activated, those
> files are undeletable, but without they are not.

I don't think the presence or absence of ACLs should make any
difference.

> >From the logs, the server seems to map ids on name, not names on id:
> Mar 20 15:33:52 stalingrad rpc.idmapd[19602]:  Server: (user) id "501"
> -> name "nobody"
> Mar 20 15:33:52 stalingrad rpc.idmapd[19602]: nfsdcb:
> authbuf=oberkampf.msr-inria.inria.fr authtype=group
> Mar 20 15:33:52 stalingrad rpc.idmapd[19602]:  Server: (group) id "501"
> -> name "nogroup"
> 
> So name-based mapping appears to be working upside down here...

The above is expected.  For example, if the client is stat'ing a file,
then the server must translate the uid and gid stored in the file's
inode into a string name that an NFSv4 client will understand.

> And what does imply idmapd translation method exactly ? Simple existence
> of user account on both side, or existence AND uid consistency ?

I'm not sure I understand the question.

If you are using NFSv4 and auth_gss, then uid's and gid's are
irrelevant.

if you are using either auth_sys, or NFSv2/v3, then you probably need
the client and server to agree on uid's and gid's.

--b.