No subject
Mon Mar 12 05:18:26 EDT 2007
> -> 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...
as bruce mentions in his response: UID/GID exist in POSIX file system, so
NFSv4 names on the wire need to be mapped to UID/GID.
have you looked at the power point presentation i refefernced? i believe all
of these questions are answered.......
Here is my idmapd configuration:
> [General]
> Verbosity = 2
> Pipefs-Directory = /var/lib/nfs/rpc_pipefs
> Domain = msr-inria.inria.fr
>
> [Mapping]
> Nobody-User = nobody
> Nobody-Group = nogroup
>
> > - 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.
> Does nsswitch even allow a unique RPCSEC_GSS principal mapping to a
> single UID, or is it impossible completly ?
no. only if your policy is to map rfc2307 name to say kerberos principal
(strip the realm) which is done for AFS. ns_switch is insufficient for
anything but the simplest NFSv4 domain.
And what does imply idmapd translation method exactly ? Simple existence
> of user account on both side, or existence AND uid consistency ?
> 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 <mailto:andros at umich.edu>, andros at citi.umich.edu
> > <mailto: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
> > <
> http://www.citi.umich.edu/projects/nfsv4/crossrealm/ASC_NFSv4_WKSHP_X_DOMAIN_N2ID.ppt
> >
> >
> > for a complete explaination.
> I'm not sure to understand everything, but at least if show some light
> on the issue. BTW, there is a small typo (joe at arbitrary.domIAn.org) on
> slide "local user: set ACL":
have you red the above powerpoint? i suggest you turn on the 'notes' in the
power point ......
It appears to me than the lighter solution, in terms of what should be
> configured on the client side, is to map on kerberos principal. This
> just implies distributing keytabs and idmapd configuration, but avoid to
> configure nss. On the other hand, it implies a LDAP server with secure
> connection on server side, and umich_ldap translation method.
>
> > 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....
> Indeed, thanks for the clarification.
>
>
------=_Part_133668_11501672.1174404601687
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br><div><span class="gmail_quote">On 3/20/07, <b class="gmail_sendername">Guillaume Rousse</b> <<a href="mailto:Guillaume.Rousse at inria.fr">Guillaume.Rousse at inria.fr</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
William A. (Andy) Adamson wrote:<br>><br>><br>> On 3/20/07, *Guillaume Rousse* <<a href="mailto:Guillaume.Rousse at inria.fr">Guillaume.Rousse at inria.fr</a><br>> <mailto:<a href="mailto:Guillaume.Rousse at inria.fr">
Guillaume.Rousse at inria.fr</a>>> wrote:<br>><br>> Hello.<br>><br>> This may seems a naive question, but I'm still trying to figure where id<br>> mapping is really needed, even after reading
<br>> <a href="http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html">http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html</a>,<br>> and trying myself.<br>><br>
> If I understand correctly:<br>> - nfs-independant nss mapping is needed anyway for operations as ls on<br>> client side, to display correctly names instead of uid<br>><br>><br>><br>> That is NFSv3. NFSv4 places names, not UID or GID on the wire - look at
<br>> the GETATTR/SETATTR owner, owner_group and ACLs.<br>Well, I'm just quoting<br><a href="http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html">http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html
</a>,<br>here "Commands such as ls still use the nsswitch infrastructure."<br><br>However, you're right, I missed it in my tests: all files belonging to<br>an user on server appears to belong to the same user on client if they
<br>also exist, even with different uid, otherwise they are listed as<br>belonging to nobody, as configured in idmapd.conf<br><br>So name-based mapping appears to work here.<br><br>BTW, I know what ACLs are, but not what are GETATTR/SETATTR owner and
<br>owner_group, sorry :(</blockquote><div><br>read the NFSv4 spec. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> - with auth_sys, file operations such as open, close, etc.. depends on
<br>> user uid, needing them to be identical on both side: again,<br>> nfs-independant nss mapping is needed. And properly-configured idmapd<br>> seems to be useless.<br>File created on client appears to be owned by the client uid on the
<br>server, </blockquote><div><br>yeah, and in NFSv4 the UID had to be mapped from the name on the wire.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
which lead to my initial claim. If ACLs are activated, those<br>files are undeletable, but without they are not.</blockquote><div><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
More information about the NFSv4
mailing list