Re: Close memory leaks in the kadm5 library

Nico Williams <[email protected]> writes:

> I don't think you want to destroy that cache always.  Looking at the
> _kadm5_c_get_cred_cache() path it seems that we support having default
> ccache with the credentials for kadmin, so we need to know if this is a
> memory ccache before we destroy it.

If this is the case, ctx->cache will be non-NULL, which will cause the
krb5_cc_destroy (and the krb5_cc_close line it replaced) to be skipped.
See the initialization of ctx->ccache in kadm5_c_init_with_context, which
in turn gets the credential cache passed into any of the kadm5_init*
functions if any (and yes, it took me a bit to trace through the code to
be sure that's what was going on as well).

Note that there's still probably a leak in kadm5_c_init_with_password,
since in that case kadm5_c_init_with_context gets a credential cache right
away and stores it in ctx->ccache.  I was tracing the _skey case, where I
pass in a keytab and creation of the credential cache is deferred to
kadm5_connect.

I'm a little confused why kadm5_c_init_with_context is storing a
credential cache in the krb5_context at all, rather than having a separate
credential cache in the kadm5_client_context that's private to that kadm5
handle, but that was more surgery than I wanted to do.

-- 
Russ Allbery ([email protected])             <http://www.eyrie.org/~eagle/>