openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5363) ldapsearch hangs when using ldap for host in nsswitch
by rra＠stanford.edu 09 Feb '08

09 Feb '08

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/>

1 0

Re: (ITS#5360) wrong default for TLSVerifyClient (with GnuTLS?)
by hyc＠symas.com 09 Feb '08

09 Feb '08

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/

1 0

Re: (ITS#5362) syncrepl provider kills consumer by sending truncated cookie
by rra＠stanford.edu 09 Feb '08

09 Feb '08

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/>

1 0

(ITS#5363) ldapsearch hangs when using ldap for host in nsswitch
by rra＠stanford.edu 09 Feb '08

09 Feb '08

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.

1 0

Re: (ITS#5362) syncrepl provider kills consumer by sending truncated cookie
by hyc＠symas.com 09 Feb '08

09 Feb '08

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/

1 0

Re: (ITS#5362) syncrepl provider kills consumer by sending truncated cookie
by hyc＠symas.com 09 Feb '08

09 Feb '08

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/

1 0

(ITS#5362) syncrepl provider kills consumer by sending truncated cookie
by quanah＠OpenLDAP.org 09 Feb '08

09 Feb '08

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

1 0

Re: (ITS#5344) Wrong check for bad Modify DN
by ando＠sys-net.it 09 Feb '08

09 Feb '08

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 ---------------------------------------

1 0

(ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
by steve.langasek＠canonical.com 08 Feb '08

08 Feb '08

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.

1 0

(ITS#5360) wrong default for TLSVerifyClient (with GnuTLS?)
by steve.langasek＠canonical.com 08 Feb '08

08 Feb '08

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.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs