Real utility of idmapd

[William A. (Andy) Adamson]

On 3/20/07, Guillaume Rousse <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.

- 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.
>
> - with gss/krb5, you need a way to map kerberos principals to uid,
> meaning idmapd with another method as nsswitch method. Otherwise, you'll
> still need identical uids on both side. And properly-configured idmapd
> seems to be useless (again).



ns_switch does not provide cross-realm name mapping, nor multiple RPCSEC_GSS
principal mapping to the same local UID, both require extra ldap fields to
be mapped. idmapd provides an api so that alternative mapping methods
(ns_switch is one method) can be used.

here at the University of Michigan, I am a member of 2 Kerberos domains and
an X.509 security realm. I can have 2 Kerberos names (andros at umich.edu,
andros at citi.umich.edu) and one SPKM3 x.509 name (something likd
ou=US,ou=Michigan,ou=University of Michigan,cn=andros) all of which I need
mapped to my local uid.

see
http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html

and
http://www.citi.umich.edu/projects/nfsv4/crossrealm/ASC_NFSv4_WKSHP_X_DOMAIN_N2ID.ppt
for a complete explaination.

So basically, if you want to get rid of the need to have identical uid
> on client and server, you need idmapping with another translation method
> than nsswitch, meaning umich_ldap, which is still considered as
> experimental (never tested it tough). Did I miss something ?



umich_ldap is experimental in that the schema used is not standardized. this
is an open issue for NFSv4. note that NFSv4 itself is labeled EXPERIMENTAL
in the kernel....

-->Andy

_______________________________________________
> NFSv4 mailing list
> NFSv4 at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/nfsv4/attachments/20070320/806ac858/attachment.htm