openldap-bugs February 2008

openldap-bugs@openldap.org

42 participants
207 discussions

(ITS#5365) Library symbol versioning or other help for library transitions
by rra＠stanford.edu 10 Feb '08

10 Feb '08

Full_Name: Russ Allbery Version: 2.4.7 OS: Debian GNU/Linux URL: Submission from: (NULL) (171.66.157.14) One of the challenges of handling core system libraries like OpenLDAP in the context of a packaged distribution is handling library transitions when the SONAME of the library changes (such as between 2.3 and 2.4, and presumably between 2.4 and 2.5). It's rarely possible to rebuild every package at the same time against the newer libraries (particularly since there are dependency chains that often require one package go first before another can be rebuilt), let alone all of the user software that's outside the space managed by the distribution. Because of that, both the old and new library usually have to co-exist for at least a brief period on many systems, with some binaries linked against the old version and some against the new version, until the upgrade is complete. This is, fundamentally, the problem of the distribution and not the problem of the OpenLDAP team. However, one thing that, from a distributor perspective, helps considerably with transitions like this is if the upstream library distributor uses symbol versioning on those platforms that support it (primarily Linux and Solaris, and possibly -- I have no personal experience -- the *BSDs). If symbol versioning is used for the libraries, the 2.3 and 2.4 libraries can be loaded into the same namespace and won't conflict with each other, since the programs and other libraries will bind to the version against which they were compiled. So, basically, this is a feature request: would it be possible to add symbol versioning to the libldap and libber libraries? Very simple symbol versioning (just assigning one version to all public symbols) would be sufficient to make these sorts of transitions much easier. I'm happy to help provide information and Makefile glue to do this if it's desirable; I've done it in a portable way with several other libraries in packages I maintain. Please feel free to tell me I should move this to a post to openldap-technical or somewhere else; I know it's sort of borderline between an ITS and a library usage discussion.

1 0

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

10 Feb '08

hyc(a)symas.com writes: > You might consider suggesting to PADL that they contribute pam/nss_ldap > to the OpenLDAP Project, if you want us to take an active role in > solving this. Until then, the discussion just doesn't belong here on the > OpenLDAP ITS. I'll note that I've described the solution Symas uses in > our commercial distribution of pam/nss-ldap on the pam/nss-ldap mailing > lists in the past. Our package has none of these issues. > > Hint: since dynamic linker dependencies are causing the conflict, the > solution is not to rely on the dynamic linker. In this particular case, > using the dynamic linker introduces a security vulnerability anyway. Understood. Thank you very much for the help that you've provided. We'll try to find a solution that won't make you hate us. :) -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5363) ldapsearch hangs when using ldap for host in nsswitch
by hyc＠symas.com 10 Feb '08

10 Feb '08

rra(a)stanford.edu wrote: > We'll talk this over and see if there's a way that we can either move from > nss-ldap or try to get it out of the places where it causes problems, > although that's going to be really rough going as you can probably > imagine. libnss-ldap has over 2,800 installations that report popcon > statistics, which means a *lot* of people are using it. > > Thinking out-loud here a bit (because I really want to solve this problem > in the long run in a way that you can support), libnss-ldap and slapd on > the same system are instant death unless everything uses libldap_r. If we > have slapd conflict with libnss-ldap and then have only slapd use > libldap_r (and make people use libnss-ldapd on systems that are also > running slapd), we may solve a fair chunk of the problem. The other place > where libldap is pulled in is via PAM, but slapd itself should never need > to call into PAM (even indirectly). You might consider suggesting to PADL that they contribute pam/nss_ldap to the OpenLDAP Project, if you want us to take an active role in solving this. Until then, the discussion just doesn't belong here on the OpenLDAP ITS. I'll note that I've described the solution Symas uses in our commercial distribution of pam/nss-ldap on the pam/nss-ldap mailing lists in the past. Our package has none of these issues. Hint: since dynamic linker dependencies are causing the conflict, the solution is not to rely on the dynamic linker. In this particular case, using the dynamic linker introduces a security vulnerability anyway. > If any slapd backends load dynamic libraries that in turn load libldap, > the world may also explode, but this should only affect back-perl, which > isn't working right now anyway due to the libtool RTLD_GLOBAL issues. >> 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.) > > Okay. I can at least pass that along to the user. Or patch nss_ldap to simply return a failure whenever it's invoked for hostname resolution. -- -- 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 10 Feb '08

10 Feb '08

Howard Chu <hyc(a)symas.com> writes: > 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. Unfortunately, I still need to figure out how best to fix the problem and that by itself doesn't give me a way, but I do understand where you're coming from. > 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. In, I should point out, a testing version as a short-term way of getting 2.4.7 into the archive so that we could throw out 2.1, which I'm sure you'd agree is a great good. :) I was always planning on trying to replace this solution with something that you felt you could support; we were just trying to do one thing at a time. We'll talk this over and see if there's a way that we can either move from nss-ldap or try to get it out of the places where it causes problems, although that's going to be really rough going as you can probably imagine. libnss-ldap has over 2,800 installations that report popcon statistics, which means a *lot* of people are using it. Thinking out-loud here a bit (because I really want to solve this problem in the long run in a way that you can support), libnss-ldap and slapd on the same system are instant death unless everything uses libldap_r. If we have slapd conflict with libnss-ldap and then have only slapd use libldap_r (and make people use libnss-ldapd on systems that are also running slapd), we may solve a fair chunk of the problem. The other place where libldap is pulled in is via PAM, but slapd itself should never need to call into PAM (even indirectly). If any slapd backends load dynamic libraries that in turn load libldap, the world may also explode, but this should only affect back-perl, which isn't working right now anyway due to the libtool RTLD_GLOBAL issues. > 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.) Okay. I can at least pass that along to the user. Thanks for the response. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

(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

← Newer
1
...
9
10
11
12
13
14
15
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2008