[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: openldap library crash
I have filed ITS #4405 for this issue. Thanks for your suggestion.
Due to our business situation, we cannot upgrade to 2.3.19 for now.
If you could make the fix available back to 2.1.22(or send us the fix
we can patch ourself), it would be great helpful.
Thanks,
-binlu
On 2/14/06, Pierangelo Masarati <ando@sys-net.it> wrote:
> I suggest you submit this as an ITS <http://www.openldap.org/its/>; it
> would be great if you could provide a simple setup, in terms of essential
> slapd.conf and corresponding LDIF data, that recreates the problem.
>
> p.
>
>
> > Hi,
> >
> > First of all, I'd like to thank your effort on making this free software,
> > which
> > has benefited us a lot in our product, an industry leading SSL VPN
> > product.
> >
> > Recently our customers(at least 2) started to complain user authentication
> > failure through ldap with recursive referral settings. The problem does
> > not
> > happen everytime, but can be reproduced with reasonable number of
> > re-try's(<20).
> >
> > We are using openldap 2.1.22 in our product. We tried the latest download
> > but it doesn't fix the problem either. We only use the openldap library in
> > the authentication side as an ldap client, authenticate against Active
> > Directory.
> >
> > Because the ldapsearch command provided by openldap does not support
> > non-anonymous rebinding in referral chasing, I am not able to provide an
> > stack trace output from that command. Here is what we have:
> >
> > Source
> > Function
> > ------ --------
> > ??:0 ??
> > ??:0 ldap_result
> > ??:0 ldap_sasl_bind
> > ??:0 ldap_sasl_interactive_bind_s
> > install/include/dsutil/str.h:595
> > DSLdapServer::connect(DSStatus *)
> > install/include/dsutil/str.h:595
> > DSLdapServer::connect(DSStatus *)
> > ??:0 ldap_new_connection
> > ??:0 ldap_send_server_request
> > ??:0 ldap_chase_v3referrals
> > ??:0 try_read1msg
> > ??:0 wait4msg
> > ??:0 ldap_result
> >
> > It shows the code entered referral chasing, and then rebind proc provided
> > by
> > us, and then ldap_sasl_bind. Our debugging shows the code actually crashes
> > in
> > libraries/libldap/result.c at
> >
> > while (rc == -2) {
> > :
> > :
> > for ( lc = ld->ld_conns; rc == -2
> > && lc != NULL;
> > lc = nextlc ) {
> > nextlc = lc->lconn_next;
> > if ( lc->lconn_status ==
> > LDAP_CONNST_CONNECTED &&
> > ldap_is_read_ready( ld,
> > lc->lconn_sb )) {
> > rc = try_read1msg(
> > ld, msgid, all,
> > lc->lconn_sb,
> > lc, result );
> > }
> > }
> > :
> > }
> >
> > In the for loop, the 'nextlc' in some cases is not NULL but invalid.
> > It either causes
> > an assertion in ldap_is_read_ready() or SEGV in access to its pointer.
> > Further
> > debugging shows in the case of assertion failure or SEGV crash, the
> > address of
> > 'nextlc' (assigned to 'lc' the next round) is freed in
> > ldap_free_connection() before
> > it reaches this loop. Not clear yet why ld->ld_conns still points to
> > that address which
> > has already been freed earlier. Would it be possible that some other
> > variables also
> > hold that value and resets it back(to ld_conns) after it is freed ?
> >
> > Saw some code changes in 2.3.19 release in this area but obviously it
> > doesn't fix this
> > problem.
> >
> > It would be greatly appreciated if you could provide us some clue &
> > help on this issue.
> > Our QA also has verified, by using a java based ldap open source
> > library, the same
> > authentication problem does not occur.
> >
> > Regards,
> > -binlu
> >
> >
>
>
>
>
>
>
> Ing. Pierangelo Masarati
>
> Responsabile Open Solution
>
> OpenLDAP Core Team
>
>
>
> SysNet s.n.c.
>
> Via Dossi, 8 - 27100 Pavia - ITALIA
>
> http://www.sys-net.it
>
> ------------------------------------------
>
> Office: +39.02.23998309
>
> Mobile: +39.333.4963172
>
> Email: pierangelo.masarati@sys-net.it
>
> ------------------------------------------
>
>
>