MEMORY keytabs - how should they be destroyed?
jaltman at secure-endpoints.com
Thu Jan 25 02:48:42 EST 2007
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
> 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_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_kt_new(krb5_context ctx, const char * type,
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_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.
More information about the krbdev