Parameterized search paths for default keytab, ccache

[Nico Williams]

On Mon, Jun 11, 2012 at 8:56 AM,  <ghudson at mit.edu> wrote:
> An offshoot of the keytab initiation design is that we plan to augment
> the default keytab and ccache to be search paths of parameterized
> keytab or ccache names, and similarly make the default client keytab a
> parameterized path.  The search path could be set at configure time by
> the OS distributor, and possibly also from a krb5.conf relation (like
> the existing default_keytab_name, or Heimdal's default_cc_name).  I'm
> not actually sure what the intended use cases are for multiple search
> path entries, but I can hypothesize:

 * To be able to build common site-local packaging of MIT Kerberos for
use on various systems where the vendor-specified lookup of ccache and
keytab varies.

> * Support a per-user acceptor without having to set KRB5_KTNAME for
>  each acceptor, but fall back to /etc/krb5.keytab if the user doesn't
>  have one.

Not likely, but, sure.

> * Support per-session ccaches (using getsid() as the parameter, I
>  guess?) without needing to set KRB5CCNAME for each session.

Job control session IDs are useless for this purpose.  It has to be
PAGs, keyrings, or similar.

> * Use a DIR ccache in /run/user, but fall back to /tmp/krb5cc_{uid} if
>  the /run/user directory hasn't been set up.

Yes.  See comment above about site-local multi-platform packaging.

> The parameterization part seems pretty straightforward.  Heimdal has a
> facility for this (expand_path.c) which we can probably adapt.

:)

> The search path part is a bit more subtle.  krb5_kt_default() and
> krb5_cc_default() do not necessarily return a keytab or ccache which
> already exists, because the caller may be intending to create and
> write to the object (e.g. kadmin ktadd, or kinit).  So "return the
> first one which exists" doesn't work.  Nico suggested that we use
> container existence (which means parent directory existence for FILE,
> directory existence for DIR, and is probably always true for
> API/KEYRING).  Is that sufficient for the keytab use cases?

I think so.  I realize that the notion of container existence here is
a bit hackish.  I think we might be able to just not do this for
keytab creation (ktadd) -always require that the user specify a keytab
path-, and as for ccache creation, always create the most-specific one
that we can create.  This causes the container existence idea to be
implied, which makes it less hackish.

Nico
--