openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#5364) Thread pool efficiency
by h.b.furuseth＠usit.uio.no 10 Feb '08

10 Feb '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: http://www.openldap.org/lists/openldap-devel/200802/msg00003.html Submission from: (NULL) (129.240.203.232) Submitted by: hallvard ITS filed for the changes in thread "Thread pool efficiency", openldap-devel, Feb 2008. slapd spends too much time contending for ltp_mutex in the thread pool (libldap_r/tpool.c). Applying some easy fixes first: Move work out of the region where pool_submit() and pool_wrapper hold the mutex locked. Also slapd/result.c checks if the pool is paused every 64 entries and if so returns LDAP_BUSY, it needs no lock for that.

1 0

Re: (ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
by hyc＠symas.com 10 Feb '08

10 Feb '08

hyc(a)symas.com wrote: > Steve Langasek wrote: >> Given that one of the errors >> returned by gnutls_x509_crt_get_subject_alt_name() is >> GNUTLS_E_SHORT_MEMORY_BUFFER, it seems obvious to me that this should use >> semantics for storage size rather than string length, and the only question >> in my mind is whether the trailing NUL is included as part of the internal >> representation of the string. >> >> If this is a behavior change as you say, then I guess we need clarification >> from GnuTLS upstream about whether this is intentional. Yes. I've just tested with GnuTLS 2.2.1 and 2.3.0 and see the same result you're seeing. The change is here: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=deaa3ac31c2… and it is clearly a bug, since subjectAltName's are not necessarily strings. (E.g., they can also be IP addresses, which are just 4 or 16 octets.) If you notice in the diff, they set *name_size = len + 1; and then later name[len] = 0; but this occurs *after* the check for SHORT_MEMORY_BUFFER. So in fact they can cause a write past the end of the supplied buffer. This patch should be reverted, it is clearly wrong. -- -- 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#5361) cert verification failures with GnuTLS and DNS subjectAltName
by hyc＠symas.com 10 Feb '08

10 Feb '08

Steve Langasek wrote: > On Sat, Feb 09, 2008 at 11:04:18PM -0800, Howard Chu wrote: >> I cannot duplicate this error with GnuTLS 1.7.8 or 1.7.9. The altname >> length that is returned just includes the non-NUL characters. Note that >> all of libldap's TLS functionality was tested and working with GnuTLS >> 1.7. What version are you using? > > Reproduced with GnuTLS 2.0.4 and GnuTLS 2.2.1. > >> It seems to me that if your version of GnuTLS is indeed behaving this way, >> then it's a GnuTLS bug, since in C, the length of a string never includes >> the trailing NUL. > > It's true that the /length/ of a string doesn't include the trailing NUL, > but it does have to be included in the storage /size/ of a C string, and > it's debatable which is intended here. Since this is an ASN.1 structure, one would ordinarily not expect any NUL termination in the first place. And since other GnuTLS library functions are returning the raw data size, excluding any trailing NUL, the behavior you're seeing here is pretty suspicious. > Given that one of the errors > returned by gnutls_x509_crt_get_subject_alt_name() is > GNUTLS_E_SHORT_MEMORY_BUFFER, it seems obvious to me that this should use > semantics for storage size rather than string length, and the only question > in my mind is whether the trailing NUL is included as part of the internal > representation of the string. > > If this is a behavior change as you say, then I guess we need clarification > from GnuTLS upstream about whether this is intentional. That sounds like the best step for now. Just to be sure, how was the certificate created? Have you verified that libldap with OpenSSL accepts the certificate correctly? So far it sounds just as likely to me that your subjectAltName actually includes a trailing NUL in its data. ASN.1 structures don't use NUL-terminated strings here, the DER form requires definite lengths to be encoded up front. -- -- 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#5361) cert verification failures with GnuTLS and DNS subjectAltName
by steve.langasek＠canonical.com 10 Feb '08

10 Feb '08

On Sat, Feb 09, 2008 at 11:04:18PM -0800, Howard Chu wrote: > I cannot duplicate this error with GnuTLS 1.7.8 or 1.7.9. The altname > length that is returned just includes the non-NUL characters. Note that > all of libldap's TLS functionality was tested and working with GnuTLS > 1.7. What version are you using? Reproduced with GnuTLS 2.0.4 and GnuTLS 2.2.1. > It seems to me that if your version of GnuTLS is indeed behaving this way, > then it's a GnuTLS bug, since in C, the length of a string never includes > the trailing NUL. It's true that the /length/ of a string doesn't include the trailing NUL, but it does have to be included in the storage /size/ of a C string, and it's debatable which is intended here. Given that one of the errors returned by gnutls_x509_crt_get_subject_alt_name() is GNUTLS_E_SHORT_MEMORY_BUFFER, it seems obvious to me that this should use semantics for storage size rather than string length, and the only question in my mind is whether the trailing NUL is included as part of the internal representation of the string. If this is a behavior change as you say, then I guess we need clarification from GnuTLS upstream about whether this is intentional.

1 0

Re: (ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
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/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. I cannot duplicate this error with GnuTLS 1.7.8 or 1.7.9. The altname length that is returned just includes the non-NUL characters. Note that all of libldap's TLS functionality was tested and working with GnuTLS 1.7. What version are you using? It seems to me that if your version of GnuTLS is indeed behaving this way, then it's a GnuTLS bug, since in C, the length of a string never includes the trailing NUL. -- -- 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#5363) ldapsearch hangs when using ldap for host in nsswitch
by hyc＠symas.com 09 Feb '08

09 Feb '08

rra(a)stanford.edu wrote: > 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. libldap_r was written solely for use by slapd and slurpd. Anybody else who uses it does so at their own risk. Applications are supposed to link with libldap. This has been stated several times before. Until somebody decides to invest some energy into writing a new C API spec, (simply dusting off the expired C API draft won't cut it) there is not and will never be any official support for threading/re-entrancy in the LDAP API. > 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.) Unfortunately your problems with libnss-ldap are outside our purview, and any ITS relating to it will just be closed/rejected. The fact that nss-ldap is essentially broken is not for us to fix. The problems you encounter from breaking our Makefiles in response to the nss-ldap problems are also obviously not for us to fix; you did that to yourself. Unofficially, I would suggest that you look into nss-ldapd. I haven't used it personally, and have no idea what's missing in the current implementation. But it at least has a fighting chance of working sanely. The other obvious step in this situation is never to use LDAP for hostname resolution. ("Doctor, it hurts when I do this." - "Don't do that.") LDAP is a much heavier weight protocol than DNS; as such it's simply the wrong tool for the job. (Note - I like using DNS servers backed by LDAP, but that's a completely different situation.) -- -- 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#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

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