Severity: important Package: slapd Version: 2.1.30-3 Applies to: Debian/Sarge
Since the bug may be related to libraries against which slapd is linked, here the whole story of probably relevant packages: ii slapd 2.1.30-3 OpenLDAP server (slapd) ii libsasl2 2.1.19-1.5 Authentication abstraction library ii libgnutls10 1.0.4-8 GNU TLS library - runtime library ii libgnutls11 1.0.16-9 GNU TLS library - runtime library ii libgnutls7 0.8.12-6 GNU TLS library - runtime library ii libio-socket-s 0.96-1 Class implementing an object oriented interf ii libnet-ssleay- 1.25-1 Perl module for Secure Sockets Layer (SSL) ii libssl0.9.7 0.9.7e-2 SSL shared libraries ii openssl 0.9.7e-2 Secure Socket Layer (SSL) binary and related Problem occurs with commands like: ldapsearch -U mailadmin -W -b 'ou=mailbox,dc=uac,dc=mgr' -Y DIGEST-MD5 -H 'ldaps://adept.mgr' or ldapsearch -U mailadmin -W -b 'ou=mailbox,dc=uac,dc=mgr' -Y DIGEST-MD5 -ZZ -H 'ldap://adept.mgr' No problems occur with: ldapsearch -U mgr -W -b 'ou=mailbox,dc=uac,dc=mgr' -Y GSSAPI -H 'ldaps://adept.mgr' or ldapsearch -D 'cn=admin,dc=mgr' -x -W -b 'ou=mailbox,dc=uac,dc=mgr' -H 'ldaps://adept.mgr' Thus the issue seems to be tied to standard SASL mechanisms over TLS. GSSAPI for some reason did never fail. DIGEST-MD5 fails almost every time. This is what happens (slapd -d 1): connection_get(12): got connid=3 connection_read(12): checking for input on id=3 ber_get_next ber_get_next: tag 0x30 len 29 contents: ber_get_next ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable) do_extended ber_scanf fmt ({m) ber: send_ldap_extended: err=0 oid= len=0 send_ldap_response: msgid=1 tag=120 err=0 ber_flush: 14 bytes to sd 12 connection_get(12): got connid=3 connection_read(12): checking for input on id=3 connection_get(12): got connid=3 connection_read(12): checking for input on id=3 TLS certificate verification: depth: 0, err: -49, subject: -unknown-, issuer: -unknown- TLS certificate verification: Error, Unknown error connection_read(12): unable to get TLS client DN error=49 id=3 connection_get(12): got connid=3 connection_read(12): checking for input on id=3 ber_get_next ber_get_next: tag 0x30 len 24 contents: do_bind ber_get_next ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable) ber_scanf fmt ({imt) ber: ber_scanf fmt ({m) ber: ber_scanf fmt (}}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_sasl_bind: dn () mech DIGEST-MD5 SASL [conn=3] Debug: DIGEST-MD5 server step 1 connection_get(12): got connid=3 connection_write(12): waking output for id=3 [... endless loop of the last two lines ...] In very rare cases, slapd recovers continuing as follows after hundreds of the loop pairs: [ ... loop ...] connection_get(12): got connid=3 connection_write(12): waking output for id=3 send_ldap_sasl: err=14 len=176 send_ldap_response: msgid=2 tag=97 err=14 ber_flush: 195 bytes to sd 12 <== slap_sasl_bind: rc=14 connection_get(12): got connid=3 connection_write(12): waking output for id=3 connection_get(12): got connid=3 connection_read(12): checking for input on id=3 ber_get_next ber_get_next: tag 0x30 len 311 contents: do_bind ber_get_next ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable) ber_scanf fmt ({imt) ber: ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: ber_scanf fmt (}}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_sasl_bind: dn () mech DIGEST-MD5 SASL [conn=3] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=mailadmin,cn=MGR,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=mailadmin,cn=MGR,cn=DIGEST-MD5,cn=auth> => ldap_bv2dn(uid=mailadmin,cn=MGR,cn=DIGEST-MD5,cn=auth,0) <= ldap_bv2dn(uid=mailadmin,cn=MGR,cn=DIGEST-MD5,cn=auth,0)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=mailadmin,cn=mgr,cn=digest-md5,cn=auth,272)=0 <<< dnNormalize: <uid=mailadmin,cn=mgr,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=mailadmin,cn=mgr,cn=digest-md5,cn=auth to a DN [ .. and so on for the standard slapd processing of the request ] Quitting slapd (^C interactively, kill -TERM, or /etc/init.d/slapd stop) can take arbitrary long time to complete, then. Interactively slapd reports that it's waiting for a thread. If you need more info, do not hesitate to ask, the issue is quite reproducible. Best regards, - lars. -- Dr. Lars Hanke µAC - Microsystem Accessory Consult Ingenieurbüro für Technologietransfer Nordstraße 60 53859 Niederkassel >> Realize the possible <<
