MEMORY keytabs - how should they be destroyed?

[Jeffrey Altman]

I am implementing the MEMORY keytab and have come across a problem.
There is no krb5_kt_destroy() function.  This means that there is no
mechanism by which a keytab can be destroyed once it is created.

Heimdal destroys the MEMORY keytab whenever the krb5_kt_close results in
a zero reference count being reached.  However, this seems wrong to me.
 If you were to apply this semantic to FILE keytabs it would be the
equivalent of deleting the keytab file whenever there are no users of
the keytab.   This semantic appears to be wrong to me.

I believe that there should be a new function:

	krb5_error_code KRB5_CALLCONV
	krb5_kt_destroy(krb5_context context, krb5_keytab keytab);

The semantics of this function are that the contents of the keytab are
destroyed.  For the FILE ccache, this would mean truncate the contents
of the file and then unlink.  For the MEMORY ccache, this would mean
empty the keytab of all entries and if it has a refcount of 0 remove the
keytab from the in-memory list.

Comments?

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20070123/6d302ad1/attachment.bin