svcgssd

Fredrik Tolf fredrik at dolda2000.com
Mon Jul 3 11:51:25 EDT 2006


On Mon, 2006-07-03 at 09:40 -0400, Kevin Coffman wrote:
> On 7/3/06, Fredrik Tolf <fredrik at dolda2000.com> wrote:
> > On Mon, 2006-07-03 at 14:54 +1000, Max Matveev wrote:
> >
> > >  fredrik> This is rather crucial, because I have a couple of cases where the
> > >  fredrik> Kerberos principal name isn't directly mappable to the system's user
> > >  fredrik> names.
> > > This is where idmapd comes in and helps to map a
> > > vasily.ivanovich at kremlin.ru to local uid 0.
> >
> > Now correct me if I'm wrong, but idmapd never knows the GSS name of a
> > user, right?
> 
> svcgssd uses the same library, libnfsidmap, that idmapd uses to map
> the GSS name to a local UID/GID.  So no, idmapd doesn't deal with GSS
> names, but svcgssd does.
> 
> There are two modes that can be used to do name/id mapping.  The
> default is "nss", using whatever method is configured in
> /etc/nsswitch.conf.  This basically assumes that you can strip off the
> @REALM part of a GSS auth name and get the local name.  If you use the
> "umich_ldap" method, user entries can (must) have a GSSAuthName LDAP
> attribute to enable mapping directly from a GSS auth name to a local
> name (uid) and uidnumber/gidnumber.

A couple of thoughts about this:

1. There already is a way of authorizing krb principals by way of the
~/.k5login file, so I don't think that it should have to be duplicated.
Would it be very hard to make the kernel pass the actual username/UID to
svcgssd? I've been looking at the code, but I haven't gotten far enough
yet to answer this question on my own. I did know about the umich_ldap
method, but I'm not very positive about setting up an LDAP server just
for the sake of NFS and then duplicating the .k5login files.
2. As it stands right now, there is still a better solution than just
stripping the realm part of the principal, since it not only creates
x-realm problems (what if an untrusted realm with x-realm auth set up
creates a principal with a conflicting name?), but also doesn't seem to
handle principals with more than one component (I often use e.g.
username/autologin at DOLDA2000.COM on my home network for gdm autologins).
Instead, the krb5_aname_to_localname() function should be used, since it
is better from the start and can also be configured in a very flexible
manner through krb5.conf. I don't know if it has a GSSAPI equivalent,
though (I've only been programming directly with the krb5 library, not
with GSSAPI).

Fredrik Tolf




More information about the NFSv4 mailing list