openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#5368) s/strncasecmp/ber_bvstrncasecmp/ broke substring check for {CLEARTEXT}
by hyc＠symas.com 10 Feb '08

10 Feb '08

steve.langasek(a)canonical.com wrote: > Full_Name: Steve Langasek > Version: 2.4.7 > OS: Debian > URL: http://people.ubuntu.com/~vorlon/sasl-cleartext-strncasecmp.patch > Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb) > > > A regression was introduced in revision 1.239 of servers/slapd/sasl.c. > Previously, sasl_ap_lookup() would check for a leading string of {CLEARTEXT} and > trim it from the userPassword value returned to SASL; but in revision 1.239, the > strncasecmp() was replaced with ber_bvstrcasecmp() which instead looks for an > exact match of the whole string, causing passwords to be handed back to SASL > with the leading "{CLEARTEXT}" attached. > > The referenced patch is verified to correct this regression. Thanks, this is now fixed in 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

(ITS#5368) s/strncasecmp/ber_bvstrncasecmp/ broke substring check for {CLEARTEXT}
by steve.langasek＠canonical.com 10 Feb '08

10 Feb '08

Full_Name: Steve Langasek Version: 2.4.7 OS: Debian URL: http://people.ubuntu.com/~vorlon/sasl-cleartext-strncasecmp.patch Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb) A regression was introduced in revision 1.239 of servers/slapd/sasl.c. Previously, sasl_ap_lookup() would check for a leading string of {CLEARTEXT} and trim it from the userPassword value returned to SASL; but in revision 1.239, the strncasecmp() was replaced with ber_bvstrcasecmp() which instead looks for an exact match of the whole string, causing passwords to be handed back to SASL with the leading "{CLEARTEXT}" attached. The referenced patch is verified to correct this regression.

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 Sun, Feb 10, 2008 at 01:19:49AM -0800, Howard Chu wrote: >> 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. Well, granted; it is consistent in newer versions of GnuTLS, though, despite being inconsistent with older versions and with the other crt APIs. >> 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? Using the openssl commandline tool, and specifying a subjectAltName=DNS:hostname entry in the [ v3_ca ] section of /etc/ssl/openssl.cnf. This was created strictly as a test certificate, in response to reports of problems precisely with subjectAltName validation (http://bugs.debian.org/462588#98). > Have you verified that libldap with OpenSSL accepts the certificate > correctly? Yes, I've tested with ldapsearch from OpenLDAP 2.3.30 linked against OpenSSL, which was able to validate the subjectAltName just fine. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

1 0

Re: (ITS#5367) test019-syncreplication-cascade fails
by hyc＠symas.com 10 Feb '08

10 Feb '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080210.tgz.1 > Submission from: (NULL) (129.240.203.232) > Submitted by: hallvard > > > "./run test019-syncreplication-cascade" fails in HEAD: > master and R2 slave databases differ Sorry about that, was poking at things that didn't need poking. Fixed in HEAD. > diff testrun/server1.out testrun/server3.out says server3 has an extra object > cn=James A Jones 2,ou=Information Technology > Division,ou=People,dc=example,dc=com > > testrun directory in enclosed, including test output in testrun/output. > > (Ignore the ftp'ed filename without ".1" at the end, transfer failed.) > > > . > -- -- 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#5367) test019-syncreplication-cascade fails
by h.b.furuseth＠usit.uio.no 10 Feb '08

10 Feb '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080210.tgz.1 Submission from: (NULL) (129.240.203.232) Submitted by: hallvard "./run test019-syncreplication-cascade" fails in HEAD: master and R2 slave databases differ diff testrun/server1.out testrun/server3.out says server3 has an extra object cn=James A Jones 2,ou=Information Technology Division,ou=People,dc=example,dc=com testrun directory in enclosed, including test output in testrun/output. (Ignore the ftp'ed filename without ".1" at the end, transfer failed.)

1 0

(ITS#5366) ldap_get_dn man page errors
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) The ldap_get_dn man page has the following prototype for ldap_str2dn: int ldap_str2dn( const char *str, LDAPDN **dn, unsigned flags ) However, ldap.h has: LDAP_F( int ) ldap_str2dn LDAP_P(( LDAP_CONST char *str, LDAPDN *dn, unsigned flags )); Note the difference for the second argument. This is related to, later in the man page: typedef struct ldap_ava { char *la_attr; struct berval *la_value; unsigned la_flags; } LDAPAVA; typedef LDAPAVA** LDAPRDN; typedef LDAPRDN** LDAPDN; but ldap.h says: typedef struct ldap_ava { struct berval la_attr; struct berval la_value; unsigned la_flags; void *la_private; } LDAPAVA; typedef LDAPAVA** LDAPRDN; typedef LDAPRDN* LDAPDN; Note the type difference for LDAPDN (which explains the earlier varience) and for la_attr. Original Debian bug report: http://bugs.debian.org/465024

1 0

(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

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