[tpop3d-discuss] Memory leak?

Chris Lightfoot chris at ex-parrot.com
Thu, 9 May 2002 23:10:38 +0100

On Thu, May 09, 2002 at 02:43:50PM -0700, Marc Lewis wrote:
> On Thu, May 09, 2002 at 09:14:03PM +0100, Chris Lightfoot wrote:
> > On Thu, May 09, 2002 at 12:08:41PM -0700, Marc Lewis wrote:
> > > On Thu, May 09, 2002 at 11:20:45AM +0100, Chris Lightfoot wrote:
> >     [...]
> > > > Cheers. I'll see if I can reproduce anything with my test
> > > > OpenLDAP installation.
> > > 
> > > I'm very interested to hear your results.  
> > 
> > OK, I've discovered a few SNAFUs; the following patch
> > ought to fix them:
> [snip]
> > 
> > -- I could have sworn that the last documentation I read
> > told me that I'd got this right before.
> I'll test this out on a test setup and we'll see what happens.
> > I can't comment on the PAM trouble you're having, except
> > for my earlier snide comments about PAM itself. I shall
> > try to dig out a more recent RedHat machine to test it
> > on, but I can't see myself installing the PAM LDAP stuff.
> > 
> > You mentioned that you'd had some spurious failed
> > authentications. What error message is logged in these
> > cases?
> After much grepping, I found this (IP/username removed):
> May  8 18:50:32 floyd tpop3d[31919]: auth_ldap_new_user_pass: ldap_search_s: Can't contact LDAP server
> May  8 18:50:32 floyd tpop3d[31919]: connection_do: client `[7]xxx.xxx.xxx.xxx/floyd.blarg.net': username `xxxxxx': 1 authentication failures
> Looking through the code leads me here:
>     /* Look for DN of user in the directory. */
>     if ((ret = ldap_search_s(ldapinfo.ldap, ldapinfo.dn, LDAP_SCOPE_SUBTREE, filter, NULL, 0, &ldapres)) != LDAP_SUCCESS) {
>         log_print(LOG_ERR, "auth_ldap_new_user_pass: ldap_search_s: %s", ldap_err2string(ret));
>         goto fail;
>     }
> Shouldn't this also been in a "for (i = 0; i < 3; ++i) {" loop as well?
> This particular error doesn't make a shole lot of sense to me since by the
> time it gets to this point in the code, it should have already done a bind
> to the server and have a connection.

Errm. To be honest, I don't like the loop in the existing
code. I also can't see why this error should occur, since,
as you say, the connection should already be bound to the
server. It is possible that the ldap_simple_bind_s call
doesn't do anything if the client library thinks that it's
already bound. It might be worth forcing a re-bind on
every authentication, by inserting
immediately before the loop.

(A quick check of the OpenLDAP source code seems to
indicate that this isn't the solution: the bind call will,
I think, always contact the server. This would mean that
the source of the error is that the connection has
evaporated between binding and searching, which seems a
bit surprising. Is there anything useful in the LDAP
server logs?)

> In 5 hours, from 2pm (when I switched to LDAP authentication) until 7pm,
> which I switched back to PAM.  There were 456 of these recorded, and about
> 16500 valid connections in that 5 hour period.

Hmm. About 2.75% of authentications. How bizarre.

Is there any patter to which clients trigger this?

``Serendipity is looking for a needle in a haystack
  and finding the farmer's daughter.'' (Hans Kornberg)