Re: gsskrb5_accept_delegated_token leaks a ccache
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/
Re: gsskrb5_accept_delegated_token leaks a ccache
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); Ah, you are running a diffrent version of what I'm using. Try apply 1.64 delta of that file, it will probably make you more happy. Love revision 1.64 date: 2006/10/25 04:19:45; author: lha; state: Exp; lines: +2 -1 (gsskrb5_accept_delegated_token): need to free ccache --- heimdal/lib/gssapi/krb5/accept_sec_context.c 7 Oct 2006 22:13:53 - 1.63 +++ heimdal/lib/gssapi/krb5/accept_sec_context.c 25 Oct 2006 04:19:45 - 1.64 @@ -181,6 +181,7 @@ gsskrb5_accept_delegated_token handle = (gsskrb5_cred) *delegated_cred_handle; handle-cred_flags |= GSS_CF_DESTROY_CRED_ON_RELEASE; + krb5_cc_close(_gsskrb5_context, ccache); ccache = NULL; }
Re: gsskrb5_accept_delegated_token leaks a ccache
On Thu, 8 Feb 2007 10:39:45 +1100 Love Hörnquist Åstrand [EMAIL PROTECTED] wrote: 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); Ah, you are running a diffrent version of what I'm using. Try apply 1.64 delta of that file, it will probably make you more happy. Mmm, somethings off. I just rsync'd and did a cvs co heimdal and the latest log entry I have is: revision 1.56 date: 2006/05/09 07:16:39; author: lha; state: Exp; lines: +3 -1 (gsskrb5_is_cfx): always set is_cfx. From Andrew Abartlet. Has the procedure changed? Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/
Re: gsskrb5_accept_delegated_token leaks a ccache
Mmm, somethings off. I just rsync'd and did a cvs co heimdal and the latest log entry I have is: revision 1.56 date: 2006/05/09 07:16:39; author: lha; state: Exp; lines: +3 -1 (gsskrb5_is_cfx): always set is_cfx. From Andrew Abartlet. Has the procedure changed? Nevermind. I found your new development page and managed to get the latest branch. Thanks, Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/
Re: gsskrb5_accept_delegated_token leaks a ccache
On Mon, 5 Feb 2007 22:24:22 -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 ... Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/
Re: gsskrb5_accept_delegated_token leaks a ccache
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. $ diff -Naur copy_ccache.c.0 copy_ccache.c --- copy_ccache.c.0 2007-02-05 23:09:58.0 -0500 +++ copy_ccache.c 2007-02-05 23:12:14.0 -0500 @@ -99,8 +99,6 @@ handle-usage = 0; if (id) { - char *str; - handle-usage |= GSS_C_INITIATE; kret = krb5_cc_get_principal(gssapi_krb5_context, id, @@ -137,14 +135,7 @@ return ret; } - kret = krb5_cc_get_full_name(gssapi_krb5_context, id, str); - if (kret) - goto out; - - kret = krb5_cc_resolve(gssapi_krb5_context, str, handle-ccache); - free(str); - if (kret) - goto out; + handle-ccache = id; } -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/
Re: gsskrb5_accept_delegated_token leaks a ccache
I can't seem to send the original message to this. I'm getting a4.sics.se[193.10.64.34] said: 550 5.7.0 Local Policy Violation (in reply to end of DATA command). There must be something in it causing the server to choke. Don't know why. Anyway here's a link: http://www.ioplex.com/~miallen/h.txt Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/