rra(a)stanford.edu writes:
> ldapsearch calls getaddrinfo inside a mutex because on many systems it's
> not thread-safe. However, this means that if libnss-ldap is in use and
> pointing to LDAP for host information, we get deadlock. ldapsearch
> calls getaddrinfo(), which calls into libnss-ldap, which tries to open a
> connection, which then hits the same lock inside the LDAP libraries.
Oh, and incidentally, if you're wondering why ldapsearch is using
libldap_r and hence getting this mutex at all, it's because of the issue
that I raised on openldap-technical (which I can also file an ITS about if
it would be appropriate). We can't ship both libldap and libldap_r and
have some applications linked against one and some against the other
because they expose the same symbols and it's caused problems in the past.
Right now, pending advice, we're taking the easiest possible solution and
just linking everything against libldap_r.
But this particular problem probably wouldn't happen without that. So one
solution may be to fix *that* problem, and any advice there is most
definitely welcome. (However, I would expect any slapd backend that
itself did a search to possibly have this same issue, so fixing ldapsearch
may not fix the full problem.)
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
steve.langasek(a)canonical.com wrote:
> Full_Name: Steve Langasek
> Version: 2.4.7
> OS: Debian
> URL: http://people.ubuntu.com/~vorlon/slapd-tlsverifyclient-default.patch
> Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb)
>
>
> The code in slapd whose purpose is to override the library default value for
> LDAP_OPT_X_TLS_REQUIRE_CERT is failing, at least when OpenLDAP is built with
> GnuTLS, because the override is done to a set of "global" options which are
> never used.
>
> The patch referenced below has been verified to fix this issue.
Thanks for the patch, committed to HEAD.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc(a)symas.com writes:
> quanah(a)OpenLDAP.org wrote:
>> Full_Name: Quanah Gibson-Mount
>> Version: 2.4.7
>> OS:
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (24.23.156.219)
>> As reported in the Debian BTS, and Howard has seen this as well:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464024
> Also, as usual, a GDB stack trace from a slapd with debug symbols would
> be useful. strace is generally useless since it only traces system
> calls, not application code. I wish whoever is telling people to provide
> strace output would quit that.
Just for reference, if you ever need to get real stack traces from people
who are using Debian packages, tell them to install slapd-dbg first. That
package contains the detached debugging information for slapd, which gdb
will pick up automatically if it's installed.
(It's still an optimized build, so the resulting backtrace may leave
something to be desired, but it's at least not completely useless.)
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
Full_Name: Russ Allbery
Version: 2.4.7
OS: Debian GNU/Linux
URL:
Submission from: (NULL) (171.64.19.147)
ldapsearch calls getaddrinfo inside a mutex because on many systems it's not
thread-safe. However, this means that if libnss-ldap is in use and pointing to
LDAP for host information, we get deadlock. ldapsearch calls getaddrinfo(),
which calls into libnss-ldap, which tries to open a connection, which then hits
the same lock inside the LDAP libraries.
Not sure the best fix for this. Removing the locks fixes the deadlock and is
safe for glibc systems since glibc's getaddrinfo is thread-safe; however, it
would not be safe on those other systems that prompted the lock in the first
place.
See http://bugs.debian.org/340601 for reference including the patch that appears
to clear the deadlock on Debian that Steve came up with while tracking the
problem down. I'm guessing that you don't want it in its current form, but it
may be useful for reference.
quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.7
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (24.23.156.219)
>
>
> As reported in the Debian BTS, and Howard has seen this as well:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464024
Also, as usual, a GDB stack trace from a slapd with debug symbols would be
useful. strace is generally useless since it only traces system calls, not
application code. I wish whoever is telling people to provide strace output
would quit that.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.7
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (24.23.156.219)
>
>
> As reported in the Debian BTS, and Howard has seen this as well:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464024
I saw a similar problem while investigating ITS#5332. While ldapadd'ing 1000
entries I saw several instances where a cookie was sent without a CSN. It
didn't result in a crash though. After sprinkling some assert's in the code I
think I've identified the problem, and the current code in HEAD no longer
triggers any of the assert's that I used. But I'm not certain that the
behavior I was chasing is the same as in this bug report. Please test and
report your results.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
h.b.furuseth(a)usit.uio.no wrote:
> hyc(a)symas.com writes:
>>> The slapd/modrdn.c check for affectsMultipleDSAs is insufficient, it
>>> requires newSuperior to be in the same backend. That does not catch
>>> moving "cn=x,cn=y" to another database's suffix "cn=z,cn=y".
>> I don't see how it can miss this.
>
> It checks if newSuperior is in another backend, but that move doesn't
> need a newSuperior. It keeps the same parent:
>
> database 1: suffix cn=y
> database 2: suffix cn=z,cn=y
> modify rdn: dn "cn=x,cn=y"; newrdn cn=z; newSuperior (if any) cn=y.
>
>> Probably should look at adding the dest_dn to the op struct, so each
>> backend doesn't have to rebuild it.
>
> Indeed. And dest_ndn.
You should apply your initial patch (to HEAD, 2.4), then modify HEAD to
pass dest_dn/dest_ndn
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
Full_Name: Steve Langasek
Version: 2.4.7
OS: Debian
URL: http://people.ubuntu.com/~vorlon/gnutls-altname-nulterminated.patch
Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb)
When built with GnuTLS, libldap fails to correctly verify DNS hostnames against
the subjectAltName field of the provided certificate. The reason for this is
that, while the "length" that gnutls returns for the CN is equal to the
strlen(), the length returned by gnutls_x509_crt_get_subject_alt_name() includes
a trailing NUL.
I have verified that the referenced patch corrects this for the case of
non-wildcard DNS subjectAltName values. I have not tested the code for the
wildcarded case, though it seems likely that the same bug applies there and will
need to be fixed.
Full_Name: Steve Langasek
Version: 2.4.7
OS: Debian
URL: http://people.ubuntu.com/~vorlon/slapd-tlsverifyclient-default.patch
Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb)
The code in slapd whose purpose is to override the library default value for
LDAP_OPT_X_TLS_REQUIRE_CERT is failing, at least when OpenLDAP is built with
GnuTLS, because the override is done to a set of "global" options which are
never used.
The patch referenced below has been verified to fix this issue.