[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/