[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Memory leak in SSL binds, OpenLDAP 2.0.23

Thanks for your very interesting response. I am slowly beginning to understand.

In the particular case I am dealing with, it seems that the sasl context is never allocated (don't know why yet) and this means that when ldap_int_sasl_external() tries to add the authid (percolated up from ldap_pvt_tls_getpeer() ), there is no context to put it into. It returns an error condition and the temporary pointer to the authid is eventually destroyed, thus leading to a leak. The problem with the leak is that frequent usage of the library over a prolonged period causes the leak to build up to become quite large.

It is very odd because it only happens for a particular server but I suppose I'll find that out why later. I have finally sorted out the debugger so that I am beginning to be able to see what's going on.

I was also rather confused about why the server's details are going into the sasl context! Thanks for confirming that this is not correct. Anyhow, I'll let you know when I find out what's going on. 

Thanks again

Regards,

Tim

Howard Chu wrote:

-----Original Message-----
From: owner-openldap-bugs@OpenLDAP.org
[mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of Tim Murphy





Ok, to continue the story, I have multiple threads connecting to
different LDAP sites. The sasl lconn_sasl_ctx variable in the LDAPConn
struct for one of my LDAP handles gets set to null somewhere. This
appears to cause a memory leak, the worst part of which is the
external.auth_id variable.



This lconn_sasl_ctx handle should only be set to NULL when closing a SASL
session, and only after calling sasl_dispose(). As such, any leaks in the
SASL context are due to the Cyrus libraries.

Just fyi, in OpenLDAP 2.0 the client sets external.auth_id to the wrong
value; it sets it to the server's cert DN but it should be set to the
client's
cert DN. This has no impact on the actual authentication, it seems to only
show up in debug messages.



I am unaware where the null setting happens and am unable to get debug
builds of ldap and sasl to work properly under gdb on solaris so it's
hard for me to trace where this problem is occuring.



The only point in the LDAP code where this is set to NULL is in
ldap_int_sasl_close.


An additional problem is that it happens to one of my threads and not
the others - always when I am connecting to a particular site (the order
in which the threads kick off does not seem to affect this).

Sorry to seem so confused  - I am struggling to understand how OpenLDAP
works and where the boundaries of it's memory-management
responsibilities are w.r.t cyrus sasl and openssl.

Regards,

Tim




-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support


Tim Murphy wrote:



Hi, I am experiencing a memory leak but I'm not sure if it's an
OpenLDAP problem or a CyrusSASL problem.
Using purify I find that during SSL connections (with simple
authentication), the authid, stored in a sasl context is not being
freed at ldap_unbind().  In the case of SSL this is seems to be the
auth information from the server (i.e. the server name, administrator
email etc right out of the server's certificate).

I am continuing to try to track this down. My apologies if I should
have discussed this on another forum.

Regards,

Tim