[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gsskrb5_accept_delegated_token leaks a ccache
On Thu, 8 Feb 2007 09:33:34 +1100
Love Hörnquist Åstrand <lha@kth.se> wrote:
> 6 feb 2007 kl. 15.14 skrev Michael B Allen:
>
> > On Mon, 5 Feb 2007 22:59:34 -0500
> > Michael B Allen <mba2000@ioplex.com> wrote:
> >>> If I simply remove the ccache = NULL line in
> >>> gsskrb5_accept_delegated_token the leak is gone, delegation works
> >>> fine
> >>> and otherwise my application seems heathy.
> >>
> >> Correction, this breaks trying to initiate with the delegated
> >> cred. Apparently that ccache does need to hang around. I will
> >> investigate
> >> further ...
> >
> > The following works for me but I find it hard to believe the code
> > removed
> > isn't important.
>
> The code tries to get a new reference to the credential cache to avoid
> having the caller to keep a open reference to the cache.
>
> With you patch the accept_delegated_token code will close "id"
> and the handle will contain a pointer to free-ed memory.
Doesn't the ccache = NULL in gsskrb5_accept_delegated_token prevent "id"
from being closed?
180 (*delegated_cred_handle)->cred_flags |= GSS_CF_DESTROY_CRED_ON_RELEASE;
181 ccache = NULL;
^^^^^^^^^^^^^^
182 }
183
184 out:
185 if (ccache) {
186 if (delegated_cred_handle == NULL)
187 krb5_cc_close(gssapi_krb5_context, ccache);
188 else
189 krb5_cc_destroy(gssapi_krb5_context, ccache);
> I'm sure you are right that there is a memory leak, but I can't
> figure out why.
Once ccache = NULL is set it's lost unless gss_krb5_import_cred does
something with it (e.g. save it).
Mike
--
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/