Parameterized search paths for default keytab, ccache

[Nico Williams]

On Mon, Jun 11, 2012 at 2:58 PM, Greg Hudson <ghudson at mit.edu> wrote:
> On 06/11/2012 03:21 PM, Nico Williams wrote:
>> Job control session IDs are useless for this purpose.  It has to be
>> PAGs, keyrings, or similar.
>
> I don't know if we can usefully implement PAGs or keyrings in the
> parameterization expansion.

Well, maybe we need a plugin interface for token expansion?  Yuck.

>> 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.
>
> Again, we don't know at krb5_kt_default/krb5_cc_default time whether the
> object is going to be created, modified, or merely read from.  Consider:

For keytabs I'm saying that the keytab name should always be
explicitly specified by the user.  Now that we're looking at separate
keytabs for initiator and acceptor credentials the need for explicitly
naming the keytab to be created becomes more urgent.

>  1. krb5_cc_default()
>  2. krb5_cc_get_name()
>  3. krb5_cc_initialize()
>
> Step 1 can't return the first ccache it can create--it doesn't have a client
> principal yet, nor does it know that the caller is creating a ccache.  And
> it can't defer the decision as to what ccache it's using, because the caller
> can ask for the name before it indicates whether it's creating or merely
> using the ccache.

First look for a ccache.  If one is found, return that.  Else return
the first one for which krb5_cc_initialize() could work.  You may need
to add an interface by which to test whether initialization is
[likely] possible.

Nico
--