--On Wednesday, February 28, 2007 1:29 PM +0200 Antonis Christofides anthony@itia.ntua.gr wrote:
I wrote:
A tls connection between a client and a 2.3.30 slapd hangs while the server is giving the certificate; but this does not happen if the server is run with -d 2 or higher, or if the client is the server itself.
My slapd is the Debian-etch-packaged 2.3.30.
Quanah Gibson-Mount quanah@stanford.edu replied:
Problems with SSL on Debian are well known, and it is due to the fact that they long ago patched OpenLDAP 2.1 to compile against GnuTLS
Thanks for the information. I downloaded and compiled 2.3.32 and I have exactly the same symptom. I used ./configure --with-tls and had to install package libssl-dev for it to work.
Could it be a dependency on a Debian shared library? While investigating whether this is the case with gnutls, I found out that the slapd package does depend on the libgnutls package, but I can't find the library dependence using ldd, and when I try "lsof|grep gnutls", slapd (the Debian slapd) isn't listed there (I can see slapd if I run "lsof|grep libssl). So either the Debian slapd does not actually use gnutls, or I don't know what's going on here (which is very likely).
The libraries compiled against GnuTLS are:
:/usr/lib> ldd libldap.so.2.0.130 liblber.so.2 => /usr/lib/liblber.so.2 (0xa7f16000) libresolv.so.2 => /lib/tls/libresolv.so.2 (0xa7f03000) libdl.so.2 => /lib/tls/libdl.so.2 (0xa7f00000) libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xa7ed3000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xa7ebe000) libgnutls.so.11 => /usr/lib/libgnutls.so.11 (0xa7e57000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xa7e48000) libc.so.6 => /lib/tls/libc.so.6 (0xa7d12000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x75555000) libtasn1.so.2 => /usr/lib/libtasn1.so.2 (0xa7d01000) libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xa7cb4000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xa7cb0000) libz.so.1 => /usr/lib/libz.so.1 (0xa7c9e000) libnsl.so.1 => /lib/tls/libnsl.so.1 (0xa7c8a000)
The problem comes when the user ID running slapd, and the user ID handling other things that load /usr/lib/libldap.so.* are the same, whether that is root or the ldap user. As soon as both sets of libraries get loaded into the same user space, problems ensue.
Now, I just ran my build of OpenLDAP 2.3.28+patches (pretty much 2.3.32) at -d 0, and did a TLS bind to it, and there was no problem. (ldapsearch -ZZZ). I also ran my build of OpenLDAP 2.3.33 at -d 0, and did a TLS bind to it, and there was no problem.
So I can't reproduce the problem you are reporting, and this is on a debian server where I'm sure that slapd is only linked against the software pieces I've built myself.
ldd slapd /usr/local/lib/libhoard.so => /usr/local/lib/libhoard.so (0x00002ba7e0e35000) /usr/lib/libdl.so => /usr/lib/libdl.so (0x00002ba7e102a000) libldap_r-2.3.so.0 => /usr/local/lib/libldap_r-2.3.so.0 (0x00002ba7e112d000) liblber-2.3.so.0 => /usr/local/lib/liblber-2.3.so.0 (0x00002ba7e1276000) libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x00002ba7e1385000) libssl.so.0.9.8 => /usr/local/lib/libssl.so.0.9.8 (0x00002ba7e149d000) libcrypto.so.0.9.8 => /usr/local/lib/libcrypto.so.0.9.8 (0x00002ba7e15e4000) libresolv.so.2 => /lib/libresolv.so.2 (0x00002ba7e185e000) libltdl.so.3 => /usr/local/lib/libltdl.so.3 (0x00002ba7e1972000) libwrap.so.0 => /lib/libwrap.so.0 (0x00002ba7e1a79000) libpthread.so.0 => /lib/libpthread.so.0 (0x00002ba7e1b83000) libc.so.6 => /lib/libc.so.6 (0x00002ba7e1c97000) libstdc++.so.6 => /usr/local/lib/libstdc++.so.6 (0x00002ba7e1ed6000) libm.so.6 => /lib/libm.so.6 (0x00002ba7e20d6000) libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x00002ba7e225c000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00002ba7e0d1f000) libnsl.so.1 => /lib/libnsl.so.1 (0x00002ba7e236a000)
Which is most everything, as you can see. ;)
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html