Parameterized search paths for default keytab, ccache

[Greg Hudson]

I'm revisiting this issue since there was some discussion of it on
yesterday's call and some new options were presented.

For background: we would like to have search lists of parameterized
defaults for keytabs and ccaches.  The implementation of search lists is
pretty clear for the case where an object already exists somewhere in
the list, but it's less clear for the case where one doesn't exist and
needs to be created (that is, kinit).

We have exposed interfaces krb5_kt_default(), krb5_kt_default_name(),
krb5_cc_default(), and krb5_cc_default_name().  A number of applications
are known to use these, both for reading and writing (at least in the
case of ccaches).  We can add new interfaces, but the existing
interfaces have to work reasonably.

The options I can see are (phrased in terms of ccaches for simplicity):

1. Punt on search lists (but still do parameterization of the default
value).

2. Test for "likely creatability" of ccaches, using access().  Note that
access() uses the ruid for setuid processes.  There may be some
time-of-check/time-of-use races with this approach (but they may not be
very interesting).

2a. As with (2), but use eaccess() where it's available.  Behavior of
setuid processes would be platform-dependent.

3. If there's no existing ccache, return a compound name.  A compound
name resolves to a compound ccache.  A compound ccache collapses to a
specific ccache when it is operated on with krb5_cc_initialize(), by
attempting to create each ccache name in turn.

I'm not wild about #3 because it probably involves a lot of code (which
would have to be duplicated for ccaches and keytabs), is a bit difficult
to understand, and probably involves putting compound names in error
messages.