Inittab launching K5start too soon

[Nico Williams]

On Fri, May 13, 2011 at 7:22 AM, Greg Hudson <ghudson at mit.edu> wrote:
> On Thu, 2011-05-12 at 13:58 -0400, Nico Williams wrote:
>> Really, what should happen is that mech_krb5's gss_init_sec_context()
>> automatically gets a TGT using a keytab if there's a keytab available.
>>  Solaris' implementation does that, though sadly it only does it for
>> processes running as root.
>
> I've thought about handling this at the ccache layer, although I was
> never comfortable with the kind of syntax required to stuff a keytab
> name, a subsidiary ccache name, and some auxiliary parameters into a
> ccache specification.
> AUTO:kt=FILE:/etc/krb5.keytab;cc=FILE:/tmp/filename;min_life=1h ... it
> doesn't seem very friendly.

I don't think the ccache layer is the right place for this.  I think
this needs to happen in krb5_get_credentials(), or in mech_krb5.

If you had to add env vars (sure, why not) I'd say add via which to
specify a default principal name:

KRB5DEFPRINC=<unparsed-principal-name>

That, together with the existing KRB5_KTNAME and KRB5CCNAME variables,
krb5.conf, and any existing ccache (e.g., with expired credentials),
would provide enough information for krb5_get_credentials().  And if
KRB5DEFPRINC was not set you'd use <username-of-euid>@<default-realm>,
and if there were no keytab entries for that, then the first principal
for which there are keytab entries.

> So, maybe it's simpler to handle it at the GSSAPI layer.  Heimdal does
> this, storing the acquired credentials in a memory ccache.  That
> approach could generate a lot of unnecessary AS-REQs, particularly in
> combination with SPNEGO.  On the plus side, it finesses the issue of
> whether to get a new credential with the keytab or use an existing one
> which is about to expire.

Existing credentials which are about to expire should be automatically
renewed (if renewable) or replaced with fresh ones (if there's a
keytab or a display on which to prompt the user, preferably via a
trusted path).  This could be done by a daemon (as in Solaris),
particularly when there's no keytab, no logged-in smartcard, and no
display, in which case a daemon is the only way to ensure that
renewable credentials are renewed.

Nico
--