On Fri, May 13, 2011 at 7:22 AM, Greg Hudson <[email protected]> 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 -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
