Re: Close memory leaks in the kadm5 library

On Thu, Dec 22, 2011 at 4:00 PM, Russ Allbery <[email protected]> wrote:
> 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).

OK, but do change the other krb5_cc_close() calls in kadm_connect().

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

I don't get it either.

Nico
--