Real utility of idmapd

[Guillaume Rousse]

William A. (Andy) Adamson wrote:
> 
> 
> On 3/20/07, *Guillaume Rousse* <Guillaume.Rousse at inria.fr
> <mailto:Guillaume.Rousse at inria.fr>> wrote:
> 
>     Hello.
> 
>     This may seems a naive question, but I'm still trying to figure where id
>     mapping is really needed, even after reading
>     http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html,
>     and trying myself.
> 
>     If I understand correctly:
>     - nfs-independant nss mapping is needed anyway for operations as ls on
>     client side, to display correctly names instead of uid 
> 
> 
> 
> That is NFSv3. NFSv4 places names, not UID or GID on the wire - look at
> the GETATTR/SETATTR owner, owner_group and ACLs.
Well, I'm just quoting
http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html,
here "Commands such as ls still use the nsswitch infrastructure."

However, you're right, I missed it in my tests: all files belonging to
an user on server appears to belong to the same user on client if they
also exist, even with different uid, otherwise they are listed as
belonging to nobody, as configured in idmapd.conf

So name-based mapping appears to work here.

BTW, I know what ACLs are, but not what are GETATTR/SETATTR owner and
owner_group, sorry :(

>     - with auth_sys, file operations such as open, close, etc.. depends on
>     user uid, needing them to be identical on both side: again,
>     nfs-independant nss mapping is needed. And properly-configured idmapd
>     seems to be useless.
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.