[Pkg-openldap-devel] Bug#381788: slapd: TLS connections fail when running as non-root

Berg, Michael michaeljberg at gmail.com
Sun Aug 13 23:42:38 UTC 2006


Quanah, Thank you for all your help on this!

I think this round of debugging finally found the problem!
(which looks like either a "libldap-2.3-0 vs. libldap2" or a "gnutls vs.
openssl" conflict in the Debian packages).


Here are the answers to the questions from Howard Chu.

> [13:21] Howard Chu: have you checked permissions on /dev/random or
> /dev/urandom ?

Yes,  here's a copy of the output

$ ls -l /dev/*random
crw-rw-rw- 1 root root 1, 8 2006-08-12 21:46 /dev/random
crw-rw-rw- 1 root root 1, 9 2006-08-12 21:47 /dev/urandom


> [13:21] Howard Chu: have you checked to see if libssl is dynamically
> linked, and the root user is getting a different library path than the
> openldap user?

libssl is dynamically linked.

The attached files slapd-maps-root.txt.gz and slapd-maps-openldap.txt.gz
are the gzip'd contents of /proc/PID/maps for slapd running as root and
slapd running as openldap respectively (for the PID of slapd each time).
They show all files that are memory mapped into the process's address space
(which includes all the linked libraries and the database files).

Due to the basic address randomization in the kernel, a diff between these
files isn't very informative.  But if you pull out just the unique file
paths with

$ zcat slapd-maps-root.txt.gz | awk '{print $6}' | sort -u > root.txt
$ zcat slapd-maps-openldap.txt.gz | awk '{print $6}' | sort -u > openldap.txt

And then do a "diff -u root.txt openldap.txt", you get the following extra
libraries listed in the version running as openldap.

/lib/libnss_ldap-2.3.6.so
/usr/lib/libgcrypt.so.11.2.1
/usr/lib/libgnutls.so.13.0.7
/usr/lib/libgpg-error.so.0.2.0
/usr/lib/liblber.so.2.0.130
/usr/lib/libldap_r.so.2.0.130
/usr/lib/libtasn1.so.3.0.5


Both the root and openldap versions include
/usr/lib/libssl.so.0.9.8
/usr/lib/libcrypto.so.0.9.8
/usr/lib/liblber-2.3.so.0.2.13
/usr/lib/libldap_r-2.3.so.0.2.13
(among many other libraries)

Here's the associated package for each of these files

Files linked to in both the root and openldap versions:
/usr/lib/libssl.so.0.9.8		-> package libssl0.9.8
/usr/lib/libcrypto.so.0.9.8		-> package libssl0.9.8
/usr/lib/liblber-2.3.so.0.2.13		-> package libldap-2.3-0
/usr/lib/libldap_r-2.3.so.0.2.13	-> package libldap-2.3-0

Files only linked to in the openldap version:
/lib/libnss_ldap-2.3.6.so		-> package libnss-ldap
/usr/lib/libgcrypt.so.11.2.1		-> package libgcrypt11
/usr/lib/libgnutls.so.13.0.7		-> package libgnutls13
/usr/lib/libgpg-error.so.0.2.0		-> package libgpg-error0
/usr/lib/liblber.so.2.0.130		-> package libldap2
/usr/lib/libldap_r.so.2.0.130		-> package libldap2
/usr/lib/libtasn1.so.3.0.5		-> package libtasn1-3


I remember reading somewhere that in Debian, libldap-2.3-0 currently links
against libssl0.9.8 and is only suppose to be used by slapd.  While
libldap2 links against libgnutls13 and is for use by all other ldap client
software.

I'm pretty sure libgnutls13 and the others got pulled in by libnss-ldap.

My system is using ldap for user accounts.  So when slapd is running as a
non-root user, I'm guessing that it looks up the UID/GID for "openldap" and
ends up pulling in libnss-ldap, libgnutls, etc (even though the "openldap"
user and group are in the passwd/shadow and group files).

Then there is probably some conflict between either
"libldap_r-2.3.so.0.2.13 and libldap_r.so.2.0.130" or
"libssl.so.0.9.8 and libgnutls.so.13.0.7"
that is causing the problems I've been experiencing.

This also explains why slapd worked correctly after a fresh reinstall of
that package, but failed on the next reboot.  To avoid system breakage
(like apt not working correctly, not being able to start new shells, etc),
I had to disable user lookup in ldap before I purged and reinstalled slapd.
 I then re-enabled it once slapd was back up.  So slapd didn't pull in
libnss-ldap when it started up - and everything worked fine until I rebooted.

I just confirmed this.  If I comment out all "ldap" entries in my
/etc/nsswitch.conf file and then restart slapd with user and group
"openldap", then "ldapsearch -x -ZZ" successfully returns everything that
it should.  And if I then uncomment, the "ldap" entries in nsswitch.conf
again, my system works - but slapd will have problems the next time it is
restarted with these settings.

So problem found - now it just needs to be either fixed or worked around.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slapd-maps-root.txt.gz
Type: application/gzip
Size: 1662 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20060813/cd2f030a/slapd-maps-root.txt-0003.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slapd-maps-openldap.txt.gz
Type: application/gzip
Size: 1958 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20060813/cd2f030a/slapd-maps-openldap.txt-0003.bin


More information about the Pkg-openldap-devel mailing list