[krbdev.mit.edu #5411] MEMORY keytab

[Ken Raeburn via RT]

On Jan 23, 2007, at 13:29, Jeffrey Altman via RT wrote:
> 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.

Me too.

> 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.

s/ccache/keytab/

Do you want to scribble over it with zero/random bytes first?  If the  
OS reuses the same disk data blocks (not guaranteed, but I suspect  
common on non-journaling file systems, since it avoids rewriting some  
metadata), that'll make it harder (not impossible) to recover the keys.

Same with SRVTAB key table type.  In fact, maybe we should have a  
"scribble over file, fsync, truncate, and unlink" utility function.

>   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.

Use the "zap" macro to make sure the keys aren't left in memory (and  
core files).

Ken