MEMORY keytabs - how should they be destroyed?

[Jeffrey Altman]

Sam Hartman wrote:
> I don't have a problem with krb5_kt_destroy() if we conclude that
> memory keytabs want to work like memory ccaches and be referenced
> through krb5_kt_resolve.
> 
> It's not very clear to me.  That seems like an excellent way for a key
> to end up being used in an unintended scope.  My recommended
> implementation would be for memory keytabs to be created giving you a
> keytab handle that you must pass to anyone who can access the key
> material.
> 
> I'd appreciate comments on this issue especially from people who have
> not spoken up.

I believe that a memory keytab should support the krb5_kt_resolve
interface.  However, I also believe that your idea of
krb5_kt_new_memory() is excellent.  It provides a method for
applications to be sure that they are not going to end up using the same
keytab in more than one thread at a time.

I wonder if it should take a flag indicating whether the keytab should
have the automatic destroy when refcount hits zero behavior.

  krb5_error_code KRB5_CALLCONV
  krb5_kt_new_memory(krb5_context ctx, krb5_boolean destroy_on_close,
                     krb5_keytab * keytab /*out */)

Speaking with Love, he has indicated the desire to be able to create
keytabs of any type with the same semantics.  In which case we would add

  krb5_error_code KRB5_CALLCONV
  krb5_kt_new(krb5_context ctx, const char * type,
              krb5_boolean destroy_on_close,
              krb5_keytab * keytab /* out */)

This provides functionality similar to the krb5_cc_new_unique() entry
point for the same reason.

I believe that the krb5_kt_destroy functionality should be provided
whether or not krb5_kt_new() is implemented.

  krb5_error_code KRB5_CALLCONV
  krb5_kt_destroy(krb5_context, krb5_keytab keytab);

For those who are not RT watchers, please note that krbdev RT 5411
contains a patch that implements a MEMORY keytab type using the destroy
on close semantics provided today by Heimdal.

Jeffrey Altman