Re: SASL/ldapsearch killeth slapd (ITS#2530)

[omalleys@msu.edu]

Im sure it could be a configuration/environmental problem but it still
seems like it should be hardy enough to not crash slapd because the auth
method failed or was invalid. I could see it returning a fail if something
went wrong with the sasl piece loading the library.  I don't see why
it would bring down the whole slapd process.

It wouldnt take much to break the ldap server if that was the case. A way
to run ldapsearch, a way to move one of the libraries, change a config, or
one of the libs gets corrupt, and the whole server is toast?? I mean if it
was running but couldnt auth, you still have the public-read only stuff
available.



--------------------------------------
  Sean O'Malley, Information Technologist
  Michigan State University
-------------------------------------

On Wed, 21 May 2003, Kurt D. Zeilenga wrote:

> This is more likely an environmental problem than a
> software bug.  For instance, this can be caused by
> the SASL library trying to bring in a dependent
> library which is incompatible with other libraries
> used by OpenLDAP Software.
>
> See the archives of the software list for discussions
> of how to isolate and resolve such problems.
>
> Kurt
>
> At 10:03 AM 5/21/2003, omalleys@msu.edu wrote:
> >Full_Name: Sean
> >Version: 2.1.19
> >OS: Linux RH 9.0/x86
> >URL:
> >Submission from: (NULL) (35.8.1.153)
> >
> >
> >[root@test-afs-1 ldapnotes]# ps -ef | grep slap
> >ldap      8711     1  0 10:41 ?        00:00:00 [slapd]
> >root      8717  8336  0 10:41 pts/0    00:00:00 grep slap
> >[root@test-afs-1 ldapnotes]# /usr/local/openldap/bin/ldapsearch  -b
> >'dc=msu,dc=edu' '(uid=*)'
> >SASL/DIGEST-MD5 authentication started
> >Please enter your password:
> >ldap_sasl_interactive_bind_s: Can't contact LDAP server (81)
> >[root@test-afs-1 ldapnotes]# ps -ef | grep slap
> >root      8721  8336  0 10:41 pts/0    00:00:00 grep slap
> >[root@test-afs-1 ldapnotes]#
> >
> >
> >I know SASL/auth/etc isn't configured correctly which is what I was trying
> >to fix. But even a totally horked configuration shouldnt crash
> >slapd.
> >
> >If I do the ldapsearch with the -x flag it works just fine.
> >
> >This is RH 9, with the default cyrus sasl stuff
> >openldap-2.1.19
> >Berkely DB 4.1.25
> >
> >Here is some better debugging information.
> >
> >conn=0 op=0 SRCH base="" scope=0 filter="(objectClass=*)"
> >conn=0 op=0 SRCH attr=supportedSASLMechanisms
> >=> test_filter
> >    PRESENT
> >=> access_allowed: search access to "" "objectClass" requested
> >=> access_allowed: backend default search access granted to "(null)"
> ><= test_filter 6
> >=> access_allowed: read access to "" "entry" requested
> >=> access_allowed: backend default read access granted to "(null)"
> >=> access_allowed: read access to "" "supportedSASLMechanisms" requested
> >=> access_allowed: backend default read access granted to "(null)"
> >conn=0 op=0 ENTRY dn=""
> >conn=0 op=0 RESULT tag=101 err=0 text=
> >daemon: select: listen=6 active_threads=0 tvp=NULL
> >daemon: activity on 1 descriptors
> >daemon: activity on: 13r
> >daemon: read activity on 13
> >conn=0 op=1 BIND dn="" method=163
> >daemon: select: listen=6 active_threads=0 tvp=NULL
> >daemon: activity on 1 descriptors
> >daemon: activity on: 13r
> >daemon: read activity on 13
> >conn=0 op=2 BIND dn="" method=163
> >Illegal instruction
>