[Date Prev][Date Next]
RE: Memory leak in SSL binds, OpenLDAP 2.0.23
> -----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
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
> 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.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
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