On Thu, 8 Feb 2007 09:33:34 +1100 Love Hörnquist Åstrand <[EMAIL PROTECTED]> wrote:
> 6 feb 2007 kl. 15.14 skrev Michael B Allen: > > > On Mon, 5 Feb 2007 22:59:34 -0500 > > Michael B Allen <[EMAIL PROTECTED]> 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/