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/
