1:18 p.m.
--On Wednesday, February 28, 2007 1:29 PM +0200 Antonis Christofides
<anthony(a)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(a)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