svcgssd

[J. Bruce Fields]

On Mon, Jul 03, 2006 at 05:51:25PM +0200, Fredrik Tolf wrote:
> 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?

The kernel doesn't know about .k5login; it doesn't really know how to
authenticate principals at all, in fact.  It justs passes those initial context
establishment patches up to svcgssd, and it's svcgssd that tells the kernel
which uid (and gid's) to associate with an incoming context.

So if we want to use .k5login files, then we need to add that support to
svcgssd somehow.

It looks like .k5login files is that they potentially allow a many->many
mapping?  So one principal can appear in multiple .k5login files?  That's just
not going to work with NFS--when you create a new file, for example, we need to
know the *one* uid we should put on that file.

This sort of model makes sense for login, because there the user actually tells
you who s/he is trying to log in as.

We could use the .k5login files anyway, and when given a choice just use some
simple rule to decide which uid to choose.  But I'm not convinced that's ever
going to work the way people expect.

> 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.

Yeah, there should be some simpler method.

> 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 suspect you're right.  We should probably also deprecate the nfs4_gss_*()
functions in libnfsidmap and do that stuff inside svcgssd, and make
libnfsidmapd deal only with NFSv4<->local name mapping.  The only reason we
really have libnfsidmap is to allow both libacl and idmapd to share the same
mapping, but neither libacl nor idmapd deals in gss principals--that's entirely
gssd/svcgssd's problem.

> I don't know if it has a GSSAPI equivalent, though (I've only been
> programming directly with the krb5 library, not with GSSAPI).

I doubt there's any gssapi equivalent.

--b.