openldap-bugs September 2011

openldap-bugs@openldap.org

32 participants
59 discussions

Re: (ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match
by Jason_Haar＠trimble.com 18 Sep '11

18 Sep '11

This is a multi-part message in MIME format. --------------020600000809090503050207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Riight - I see what you mean now. I mis-read the debugging messages as meaning it had reconnected without TLS. Retesting with a sniffer shows otherwise. So "-Z" works as I had hoped - excellent Thanks! Jason On 19/09/11 15:22, Kurt Zeilenga wrote: > > On Sep 18, 2011, at 5:41 PM, Jason_Haar(a)trimble.com wrote: > > > Full_Name: Jason Haar > > Version: 2.4.21 > > OS: Fedora > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (222.154.246.214) > > > > > > As you know, LDAP passwords are sent in cleartext unless TLS or SASL > are used. > > Depending on TLS cipher suites and SASL mechnanism choice, of course. > > And you shouldn't be using a cleartext mechanism unless you've first > authenticated the server. > > > > > However, "ldapsearch -Z" will fall-back onto cleartext if any form > of TLS error > > occurs, even the non-fatal "TLS: hostname does not match CN in peer > certificate" > > error. > > Actually, ldapsearch(1) does not fall back into cleartext in this > case. The OpenLDAP library, and most servers, wisely don't support > stop TLS. > > What ldapsearch(1) does is, if told to check certs (the default) and > they are bad, is to terminate the session and exit. > > > > i.e. TLS is attempted, the hostname doesn't match, so ldapsearch > tries again not > > using TLS! > > No it doesn't. > > > > > This seems wasteful to me. It is still *more secure* to continue the > encrypted > > TLS session than to fallback onto cleartext. > > No, it's not. If you continued to use TLS, there is no server > authentication. Use of cleartext mechanism to an unauthenticated > server is quite insecure. > > Now it might seem that if one said use simple bind w/ password and -Z, > that it would be reasonable to assume the user didn't care about > server authentication (or data integrity/confidential). But -Z is > designed less for use with simple bind w/ password but with SASL > mechanisms. > > Now, if you really want to do that, just tell ldapsearch(1) not to do > cert checks. > > > > Web browsers are a good example of > > this: if you connect to a self-signed https site, you can choose to > continue - > > as untrusted https is still secured against other attackers. > > And some browsers are stupid enough to do basic authentication without > first authenticating the server. > > > > If a user wants to guarantee the trustworthiness of their ldapsearch > session, > > they can use "-ZZ" to achieve that - but I can't see any reason to > stop people > > using "-Z" if they want to? > > Nothing stops those who don't want cert checks from disabling them. > > > (I'm using ldapsearch to dump Active Directory LDAP data via the DNS > round-robin > > entry for the domain name: as such the LDAP host *never* matches the > hostname > > DNS round-robin gives back - and I don't care - I just don't want > the network > > group sniffing my password ;-) > > Then you likely should be doing -ZZ (because you care about > eavesdropping) while disabling the cert checks (because you seem to > not care that you might be sending your password to a man-in-the-middle). > > -- Kurt > -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 --------------020600000809090503050207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Riight - I see what you mean now. I mis-read the debugging messages as meaning it had reconnected without TLS. Retesting with a sniffer shows otherwise. So "-Z" works as I had hoped - excellent Thanks! Jason On 19/09/11 15:22, Kurt Zeilenga wrote: <blockquote cite="mid:F5AC234D-558A-4BFE-A053-EDB0B082FC41@openldap.org" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta name="Generator" content="MS Exchange Server version 6.5.7654.12"> <title>Re: (ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match</title>  On Sep 18, 2011, at 5:41 PM, <a class="moz-txt-link-abbreviated" href="mailto:Jason_Haar@trimble.com">Jason_Haar(a)trimble.com</a> wrote: > Full_Name: Jason Haar > Version: 2.4.21 > OS: Fedora > URL: <a moz-do-not-send="true" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (222.154.246.214) > > > As you know, LDAP passwords are sent in cleartext unless TLS or SASL are used. Depending on TLS cipher suites and SASL mechnanism choice, of course. And you shouldn't be using a cleartext mechanism unless you've first authenticated the server. > > However, "ldapsearch -Z" will fall-back onto cleartext if any form of TLS error > occurs, even the non-fatal "TLS: hostname does not match CN in peer certificate" > error. Actually, ldapsearch(1) does not fall back into cleartext in this case.  The OpenLDAP library, and most servers, wisely don't support stop TLS. What ldapsearch(1) does is, if told to check certs (the default) and they are bad, is to terminate the session and exit. > > i.e. TLS is attempted, the hostname doesn't match, so ldapsearch tries again not > using TLS! No it doesn't. > > This seems wasteful to me. It is still *more secure* to continue the encrypted > TLS session than to fallback onto cleartext. No, it's not.  If you continued to use TLS, there is no server authentication.  Use of cleartext mechanism to an unauthenticated server is quite insecure. Now it might seem that if one said use simple bind w/ password and -Z, that it would be reasonable to assume the user didn't care about server authentication (or data integrity/confidential).   But -Z is designed less for use with simple bind w/ password but with SASL mechanisms. Now, if you really want to do that, just tell ldapsearch(1) not to do cert checks. > Web browsers are a good example of > this: if you connect to a self-signed https site, you can choose to continue - > as untrusted https is still secured against other attackers. And some browsers are stupid enough to do basic authentication without first authenticating the server. > > If a user wants to guarantee the trustworthiness of their ldapsearch session, > they can use "-ZZ" to achieve that - but I can't see any reason to stop people > using "-Z" if they want to? Nothing stops those who don't want cert checks from disabling them. > (I'm using ldapsearch to dump Active Directory LDAP data via the DNS round-robin > entry for the domain name: as such the LDAP host *never* matches the hostname > DNS round-robin gives back - and I don't care - I just don't want the network > group sniffing my password ;-) Then you likely should be doing -ZZ (because you care about eavesdropping) while disabling the cert checks (because you seem to not care that you might be sending your password to a man-in-the-middle). -- Kurt </blockquote> <pre class="moz-signature" cols="72">-- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 </pre> </body> </html> --------------020600000809090503050207--

1 0

Re: (ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match
by kurt＠OpenLDAP.org 18 Sep '11

18 Sep '11

On Sep 18, 2011, at 5:41 PM, Jason_Haar(a)trimble.com wrote: > Full_Name: Jason Haar > Version: 2.4.21 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (222.154.246.214) > > > As you know, LDAP passwords are sent in cleartext unless TLS or SASL are used. Depending on TLS cipher suites and SASL mechnanism choice, of course. And you shouldn't be using a cleartext mechanism unless you've first authenticated the server. > > However, "ldapsearch -Z" will fall-back onto cleartext if any form of TLS error > occurs, even the non-fatal "TLS: hostname does not match CN in peer certificate" > error. Actually, ldapsearch(1) does not fall back into cleartext in this case. The OpenLDAP library, and most servers, wisely don't support stop TLS. What ldapsearch(1) does is, if told to check certs (the default) and they are bad, is to terminate the session and exit. > > i.e. TLS is attempted, the hostname doesn't match, so ldapsearch tries again not > using TLS! No it doesn't. > > This seems wasteful to me. It is still *more secure* to continue the encrypted > TLS session than to fallback onto cleartext. No, it's not. If you continued to use TLS, there is no server authentication. Use of cleartext mechanism to an unauthenticated server is quite insecure. Now it might seem that if one said use simple bind w/ password and -Z, that it would be reasonable to assume the user didn't care about server authentication (or data integrity/confidential). But -Z is designed less for use with simple bind w/ password but with SASL mechanisms. Now, if you really want to do that, just tell ldapsearch(1) not to do cert checks. > Web browsers are a good example of > this: if you connect to a self-signed https site, you can choose to continue - > as untrusted https is still secured against other attackers. And some browsers are stupid enough to do basic authentication without first authenticating the server. > > If a user wants to guarantee the trustworthiness of their ldapsearch session, > they can use "-ZZ" to achieve that - but I can't see any reason to stop people > using "-Z" if they want to? Nothing stops those who don't want cert checks from disabling them. > (I'm using ldapsearch to dump Active Directory LDAP data via the DNS round-robin > entry for the domain name: as such the LDAP host *never* matches the hostname > DNS round-robin gives back - and I don't care - I just don't want the network > group sniffing my password ;-) Then you likely should be doing -ZZ (because you care about eavesdropping) while disabling the cert checks (because you seem to not care that you might be sending your password to a man-in-the-middle). -- Kurt

1 0

(ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match
by Jason_Haar＠trimble.com 18 Sep '11

18 Sep '11

Full_Name: Jason Haar Version: 2.4.21 OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (222.154.246.214) As you know, LDAP passwords are sent in cleartext unless TLS or SASL are used. However, "ldapsearch -Z" will fall-back onto cleartext if any form of TLS error occurs, even the non-fatal "TLS: hostname does not match CN in peer certificate" error. i.e. TLS is attempted, the hostname doesn't match, so ldapsearch tries again not using TLS! This seems wasteful to me. It is still *more secure* to continue the encrypted TLS session than to fallback onto cleartext. Web browsers are a good example of this: if you connect to a self-signed https site, you can choose to continue - as untrusted https is still secured against other attackers. If a user wants to guarantee the trustworthiness of their ldapsearch session, they can use "-ZZ" to achieve that - but I can't see any reason to stop people using "-Z" if they want to? (I'm using ldapsearch to dump Active Directory LDAP data via the DNS round-robin entry for the domain name: as such the LDAP host *never* matches the hostname DNS round-robin gives back - and I don't care - I just don't want the network group sniffing my password ;-)

1 0

make error for signal.c
by Ropp, Gary 18 Sep '11

18 Sep '11

I have successfully run ./configure --disable-slapd and make depend. When I run make, I get the following errors: [dwadmin@erptestdb:DGWT]$make Making all in /var/openldap/openldap-2.4.23 Entering subdirectory include Entering subdirectory libraries Making all in /var/openldap/openldap-2.4.23/libraries Entering subdirectory liblutil rm -f version.c ../../build/mkversion -v "2.4.23" liblutil.a > version.c /usr/sfw/bin/gcc -O2 -ansi -Wno-main -DAVALON -DNO_CISAM -DORACLE -DDWLDAP -I../../include -I../../include -c signal.c signal.c: In function `lutil_sigaction': signal.c:25: error: storage size of 'action' isn't known signal.c:25: error: storage size of 'oaction' isn't known *** Error code 1 make: Fatal error: Command failed for target `signal.o' Current working directory /var/openldap/openldap-2.4.23/libraries/liblutil *** Error code 1 The following command caused the error: for i in liblutil liblber liblunicode libldap libldap_r librewrite ; do \ echo " Entering subdirectory $i"; \ ( cd $i; /usr/ccs/bin/make all ); \ if test $? != 0 ; then exit 1; fi ; \ echo " "; \ done make: Fatal error: Command failed for target `all-common' Current working directory /var/openldap/openldap-2.4.23/libraries *** Error code 1 The following command caused the error: for i in include libraries clients servers tests doc ; do \ echo " Entering subdirectory $i"; \ ( cd $i; /usr/ccs/bin/make all ); \ if test $? != 0 ; then exit 1; fi ; \ echo " "; \ done make: Fatal error: Command failed for target `all-common' Not sure if this problem compiling signal.c is a bug or not. The include file, signal.h appears to be in the correct place. Gary Ropp Senior Programmer College of the Siskiyous 530-938-5553

2 1

Re: (ITS#7044) objectIdentifier not usable for reference in objectClass' MUST or MAY clause
by hyc＠symas.com 18 Sep '11

18 Sep '11

carsten.klein(a)axn-software.de wrote: > Full_Name: Carsten Klein > Version: 2.4.23 > OS: Kubuntu 11.01 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.54.26.231) > > > I tried to get rid of the global namespace restrictions regarding attributeType > names by declaring objectIdentifierS for each of the attributeTypeS forefront > and then use these both for declaring the attributeTypeS and also using them for > reference in a MAY or MUST clause in the declared objectClassES > > While the attributeType declaration works just fine, the objectClassES will not > be parsed, resulting in an error stating that the OID cannot be resolved. > > How to reproduce: > > > objectIdentifier fooOID 1.3.6.1.4.1.123456789 > objectIdentifier fooAttrOID fooOID:1 > objectIdentifier fooClassOID fooOID:2 > > attributeType ( fooAttrOID NAME 'fooAttr' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > objectClass ( fooClassOID NAME 'fooClass' SUP top STRUCTURAL > MAY ( fooAttrOID ) ) > > will not work as expected. > > However, replacing fooAttrOID in the above objectClass declaration by either > fooAttr or 1.3.6.1.4.1.38570.1 will produce a valid ldif when run through > slaptest. > > I believe that the expected behaviour should be that the declared > objectIdentifier fooAttrOID should also be recognized when parsing the MAY or > MUST clause of the objectClass declaration. > > Or is there a way to force slaptest to recognize it? This is not supported. It is normal practice to use the canonical names of attributes in objectclass definitions, for readability. -- -- Howard Chu CTO, 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#7043) double free or corruption error
by hyc＠symas.com 18 Sep '11

18 Sep '11

szinski(a)richmond.edu wrote: > Full_Name: Steve Zinski > Version: 2.4.23 > OS: RHEL6 x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.166.34.143) Looks like this is the same as ITS#7034, closing this one. > > *** glibc detected *** slapd: double free or corruption (fasttop): > 0x00007f798831b2c0 *** > ======= Backtrace: ========= > /lib64/libc.so.6(+0x379a875146)[0x7f79c5ee7146] > /usr/lib64/libnsspem.so(+0x18e72)[0x7f79ae93ae72] > /usr/lib64/libnsspem.so(+0xa4f4)[0x7f79ae92c4f4] > /usr/lib64/libnsspem.so(+0xa64d)[0x7f79ae92c64d] > /usr/lib64/libnsspem.so(+0x1806f)[0x7f79ae93a06f] > /usr/lib64/libnsspem.so(+0x14491)[0x7f79ae936491] > /usr/lib64/libnss3.so(+0x37a184f55d)[0x7f79c6ccf55d] > /usr/lib64/libnss3.so(+0x37a18500c8)[0x7f79c6cd00c8] > /usr/lib64/libnss3.so(PK11_PubUnwrapSymKey+0xac)[0x7f79c6cd071c] > /usr/lib64/libssl3.so(+0x37a1012d52)[0x7f79c71f9d52] > /usr/lib64/libssl3.so(+0x37a1013e30)[0x7f79c71fae30] > /usr/lib64/libssl3.so(+0x37a10148cc)[0x7f79c71fb8cc] > /usr/lib64/libssl3.so(SSL_ForceHandshake+0x4f)[0x7f79c720562f] > slapd(+0x16ee65)[0x7f79c8392e65] > slapd(ldap_pvt_tls_accept+0x77)[0x7f79c8392097] > slapd(+0x4a8bb)[0x7f79c826e8bb] > slapd(+0x149c18)[0x7f79c836dc18] > /lib64/libpthread.so.0(+0x379b0077e1)[0x7f79c62087e1] > /lib64/libc.so.6(clone+0x6d)[0x7f79c5f5777d] > ======= Memory map: ======== > 7f7980000000-7f7980b86000 rw-p 00000000 00:00 0 > 7f7980b86000-7f7984000000 ---p 00000000 00:00 0 > 7f7986de1000-7f7986df7000 r-xp 00000000 fd:00 1572887 > /lib64/libgcc_s-4.4.5-20110214.so.1 > 7f7986df7000-7f7986ff6000 ---p 00016000 fd:00 1572887 > /lib64/libgcc_s-4.4.5-20110214.so.1 > 7f7986ff6000-7f7986ff7000 rw-p 00015000 fd:00 1572887 > /lib64/libgcc_s-4.4.5-20110214.so.1 > 7f7986ffe000-7f7988000000 rw-p 00000000 00:00 0 > 7f7988000000-7f7988a3e000 rw-p 00000000 00:00 0 > 7f7988a3e000-7f798c000000 ---p 00000000 00:00 0 > 7f798c000000-7f798c3de000 rw-p 00000000 00:00 0 > 7f798c3de000-7f7990000000 ---p 00000000 00:00 0 > 7f7990000000-7f79904bb000 rw-p 00000000 00:00 0 > 7f79904bb000-7f7994000000 ---p 00000000 00:00 0 > 7f79947fc000-7f79947fd000 ---p 00000000 00:00 0 > 7f79947fd000-7f7998000000 rw-p 00000000 00:00 0 > 7f7998000000-7f7998b64000 rw-p 00000000 00:00 0 > 7f7998b64000-7f799c000000 ---p 00000000 00:00 0 > 7f799c7fb000-7f799c7fc000 ---p 00000000 00:00 0 > 7f799c7fc000-7f799effe000 rw-p 00000000 00:00 0 > 7f799effe000-7f799efff000 ---p 00000000 00:00 0 > 7f799efff000-7f799f7ff000 rw-p 00000000 00:00 0 > 7f799f7ff000-7f799f800000 ---p 00000000 00:00 0 > 7f799f800000-7f79a0000000 rw-p 00000000 00:00 0 > 7f79a0000000-7f79a1b52000 rw-p 00000000 00:00 0 > 7f79a1b52000-7f79a4000000 ---p 00000000 00:00 0 > 7f79a4000000-7f79a4bb2000 rw-p 00000000 00:00 0 > 7f79a4bb2000-7f79a8000000 ---p 00000000 00:00 0 > 7f79a8000000-7f79a8021000 rw-p 00000000 00:00 0 > 7f79a8021000-7f79ac000000 ---p 00000000 00:00 0 > 7f79ac3bb000-7f79ac3bc000 ---p 00000000 00:00 0 > 7f79ac3bc000-7f79acbbc000 rw-p 00000000 00:00 0 > 7f79acbbc000-7f79acbbd000 ---p 00000000 00:00 0 > 7f79acbbd000-7f79ae922000 rw-p 00000000 00:00 0 > 7f79ae922000-7f79ae954000 r-xp 00000000 fd:00 1707035 > /usr/lib64/libnsspem.so > 7f79ae954000-7f79aeb53000 ---p 00032000 fd:00 1707035 > /usr/lib64/libnsspem.so > 7f79aeb53000-7f79aeb59000 rw-p 00031000 fd:00 1707035 > /usr/lib64/libnsspem.so > 7f79aeb59000-7f79aebe5000 r-xp 00000000 fd:00 1708690 > /usr/lib64/libsqlite3.so.0.8.6 > 7f79aebe5000-7f79aede4000 ---p 0008c000 fd:00 1708690 > /usr/lib64/libsqlite3.so.0.8.6 > 7f79aede4000-7f79aede8000 rw-p 0008b000 fd:00 1708690 > /usr/lib64/libsqlite3.so.0.8.6 > 7f79aede8000-7f79aee24000 r-xp 00000000 fd:00 1706243 > /usr/lib64/libsoftokn3.so > 7f79aee24000-7f79af024000 ---p 0003c000 fd:00 1706243 > /usr/lib64/libsoftokn3.so > 7f79af024000-7f79af026000 rw-p 0003c000 fd:00 1706243 > /usr/lib64/libsoftokn3.so > 7f79af026000-7f79af027000 ---p 00000000 00:00 0 > 7f79af027000-7f79af827000 rw-p 00000000 00:00 0 > 7f79af827000-7f79af828000 ---p 00000000 00:00 0 > 7f79af828000-7f79b0028000 rw-p 00000000 00:00 0 > 7f79b0028000-7f79b00e2000 rw-s 00000000 fd:00 919129 > /var/lib/ldap/__db.005 > 7f79b00e2000-7f79b0322000 rw-s 00000000 fd:00 919128 > /var/lib/ldap/__db.004 > 7f79b0322000-7f79c4324000 rw-s 00000000 fd:00 919125 > /var/lib/ldap/__db.003 > 7f79c4324000-7f79c4bd2000 rw-s 00000000 fd:00 918259 > /var/lib/ldap/__db.002 > 7f79c4bd2000-7f79c4bd6000 r-xp 00000000 fd:00 1705113 > /usr/lib64/sasl2/libanonymous.so.2.0.23 > 7f79c4bd6000-7f79c4dd5000 ---p 00004000 fd:00 1705113 > /usr/lib64/sasl2/libanonymous.so.2.0.23 > 7f79c4dd5000-7f79c4dd6000 rw-p 00003000 fd:00 1705113 > /usr/lib64/sasl2/libanonymous.so.2.0.23 > 7f79c4dd6000-7f79c4ddb000 r-xp 00000000 fd:00 1705116 > /usr/lib64/sasl2/libsasldb.so.2.0.23 > 7f79c4ddb000-7f79c4fda000 ---p 00005000 fd:00 1705116 > /usr/lib64/sasl2/libsasldb.so.2.0.23 > 7f79c4fda000-7f79c4fdb000 rw-p 00004000 fd:00 1705116 > /usr/lib64/sasl2/libsasldb.so.2.0.23 > 7f79c4fdb000-7f79c4fdf000 r-xp 00000000 fd:00 1710213 > /usr/lib64/sasl2/libplain.so.2.0.23 > 7f79c4fdf000-7f79c51de000 ---p 00004000 fd:00 1710213 > /usr/lib64/sasl2/libplain.so.2.0.23 > 7f79c51de000-7f79c51df000 rw-p 00003000 fd:00 1710213 > /usr/lib64/sasl2/libplain.so.2.0.23 > 7f79c51df000-7f79c51e3000 r-xp 00000000 fd:00 1710210 > /usr/lib64/sasl2/liblogin.so.2.0.23 > 7f79c51e3000-7f79c53e2000 ---p 00004000 fd:00 1710210 > /usr/lib64/sasl2/liblogin.so.2.0.23 > 7f79c53e2000-7f79c53e3000 rw-p 00003000 fd:00 1710210 > /usr/lib64/sasl2/liblogin.so.2.0.23 > 7f79c53e3000-7f79c53e8000 r-xp 00000000 fd:00 1572890 > /lib64/libnss_dns-2.12.so > 7f79c53e8000-7f79c55e7000 ---p 00005000 fd:00 1572890 > /lib64/libnss_dns-2.12.so > 7f79c55e7000-7f79c55e8000 r--p 00004000 fd:00 1572890 > /lib64/libnss_dns-2.12.so > 7f79c55e8000-7f79c55e9000 rw-p 00005000 fd:00 1572890 > /lib64/libnss_dns-2.12.so > 7f79c55e9000-7f79c55f5000 r-xp 00000000 fd:00 1573202 > /lib64/libnss_files-2.12.so > 7f79c55f5000-7f79c57f5000 ---p 0000c000 fd:00 1573202 > /lib64/libnss_files-2.12.so > 7f79c57f5000-7f79c57f6000 r--p 0000c000 fd:00 1573202 > /lib64/libnss_files-2.12.so > 7f79c57f6000-7f79c57f7000 rw-p 0000d000 fd:00 1573202 > /lib64/libnss_files-2.12.so > 7f79c57f7000-7f79c580c000 r-xp 00000000 fd:00 1573233 > /lib64/libz.so.1.2.3 > 7f79c580c000-7f79c5a0b000 ---p 00015000 fd:00 1573233 > /lib64/libz.so.1.2.3 > 7f79c5a0b000-7f79c5a0c000 rw-p 00014000 fd:00 1573233 > /lib64/libz.so.1.2.3 > 7f79c5a0c000-7f79c5a69000 r-xp 00000000 fd:00 1572935 > /lib64/libfreebl3.soAborted > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7044) objectIdentifier not usable for reference in objectClass' MUST or MAY clause
by carsten.klein＠axn-software.de 15 Sep '11

15 Sep '11

Full_Name: Carsten Klein Version: 2.4.23 OS: Kubuntu 11.01 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.54.26.231) I tried to get rid of the global namespace restrictions regarding attributeType names by declaring objectIdentifierS for each of the attributeTypeS forefront and then use these both for declaring the attributeTypeS and also using them for reference in a MAY or MUST clause in the declared objectClassES While the attributeType declaration works just fine, the objectClassES will not be parsed, resulting in an error stating that the OID cannot be resolved. How to reproduce: objectIdentifier fooOID 1.3.6.1.4.1.123456789 objectIdentifier fooAttrOID fooOID:1 objectIdentifier fooClassOID fooOID:2 attributeType ( fooAttrOID NAME 'fooAttr' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectClass ( fooClassOID NAME 'fooClass' SUP top STRUCTURAL MAY ( fooAttrOID ) ) will not work as expected. However, replacing fooAttrOID in the above objectClass declaration by either fooAttr or 1.3.6.1.4.1.38570.1 will produce a valid ldif when run through slaptest. I believe that the expected behaviour should be that the declared objectIdentifier fooAttrOID should also be recognized when parsing the MAY or MUST clause of the objectClass declaration. Or is there a way to force slaptest to recognize it?

1 0

(ITS#7043) double free or corruption error
by szinski＠richmond.edu 13 Sep '11

13 Sep '11

Full_Name: Steve Zinski Version: 2.4.23 OS: RHEL6 x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.166.34.143) *** glibc detected *** slapd: double free or corruption (fasttop): 0x00007f798831b2c0 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x379a875146)[0x7f79c5ee7146] /usr/lib64/libnsspem.so(+0x18e72)[0x7f79ae93ae72] /usr/lib64/libnsspem.so(+0xa4f4)[0x7f79ae92c4f4] /usr/lib64/libnsspem.so(+0xa64d)[0x7f79ae92c64d] /usr/lib64/libnsspem.so(+0x1806f)[0x7f79ae93a06f] /usr/lib64/libnsspem.so(+0x14491)[0x7f79ae936491] /usr/lib64/libnss3.so(+0x37a184f55d)[0x7f79c6ccf55d] /usr/lib64/libnss3.so(+0x37a18500c8)[0x7f79c6cd00c8] /usr/lib64/libnss3.so(PK11_PubUnwrapSymKey+0xac)[0x7f79c6cd071c] /usr/lib64/libssl3.so(+0x37a1012d52)[0x7f79c71f9d52] /usr/lib64/libssl3.so(+0x37a1013e30)[0x7f79c71fae30] /usr/lib64/libssl3.so(+0x37a10148cc)[0x7f79c71fb8cc] /usr/lib64/libssl3.so(SSL_ForceHandshake+0x4f)[0x7f79c720562f] slapd(+0x16ee65)[0x7f79c8392e65] slapd(ldap_pvt_tls_accept+0x77)[0x7f79c8392097] slapd(+0x4a8bb)[0x7f79c826e8bb] slapd(+0x149c18)[0x7f79c836dc18] /lib64/libpthread.so.0(+0x379b0077e1)[0x7f79c62087e1] /lib64/libc.so.6(clone+0x6d)[0x7f79c5f5777d] ======= Memory map: ======== 7f7980000000-7f7980b86000 rw-p 00000000 00:00 0 7f7980b86000-7f7984000000 ---p 00000000 00:00 0 7f7986de1000-7f7986df7000 r-xp 00000000 fd:00 1572887 /lib64/libgcc_s-4.4.5-20110214.so.1 7f7986df7000-7f7986ff6000 ---p 00016000 fd:00 1572887 /lib64/libgcc_s-4.4.5-20110214.so.1 7f7986ff6000-7f7986ff7000 rw-p 00015000 fd:00 1572887 /lib64/libgcc_s-4.4.5-20110214.so.1 7f7986ffe000-7f7988000000 rw-p 00000000 00:00 0 7f7988000000-7f7988a3e000 rw-p 00000000 00:00 0 7f7988a3e000-7f798c000000 ---p 00000000 00:00 0 7f798c000000-7f798c3de000 rw-p 00000000 00:00 0 7f798c3de000-7f7990000000 ---p 00000000 00:00 0 7f7990000000-7f79904bb000 rw-p 00000000 00:00 0 7f79904bb000-7f7994000000 ---p 00000000 00:00 0 7f79947fc000-7f79947fd000 ---p 00000000 00:00 0 7f79947fd000-7f7998000000 rw-p 00000000 00:00 0 7f7998000000-7f7998b64000 rw-p 00000000 00:00 0 7f7998b64000-7f799c000000 ---p 00000000 00:00 0 7f799c7fb000-7f799c7fc000 ---p 00000000 00:00 0 7f799c7fc000-7f799effe000 rw-p 00000000 00:00 0 7f799effe000-7f799efff000 ---p 00000000 00:00 0 7f799efff000-7f799f7ff000 rw-p 00000000 00:00 0 7f799f7ff000-7f799f800000 ---p 00000000 00:00 0 7f799f800000-7f79a0000000 rw-p 00000000 00:00 0 7f79a0000000-7f79a1b52000 rw-p 00000000 00:00 0 7f79a1b52000-7f79a4000000 ---p 00000000 00:00 0 7f79a4000000-7f79a4bb2000 rw-p 00000000 00:00 0 7f79a4bb2000-7f79a8000000 ---p 00000000 00:00 0 7f79a8000000-7f79a8021000 rw-p 00000000 00:00 0 7f79a8021000-7f79ac000000 ---p 00000000 00:00 0 7f79ac3bb000-7f79ac3bc000 ---p 00000000 00:00 0 7f79ac3bc000-7f79acbbc000 rw-p 00000000 00:00 0 7f79acbbc000-7f79acbbd000 ---p 00000000 00:00 0 7f79acbbd000-7f79ae922000 rw-p 00000000 00:00 0 7f79ae922000-7f79ae954000 r-xp 00000000 fd:00 1707035 /usr/lib64/libnsspem.so 7f79ae954000-7f79aeb53000 ---p 00032000 fd:00 1707035 /usr/lib64/libnsspem.so 7f79aeb53000-7f79aeb59000 rw-p 00031000 fd:00 1707035 /usr/lib64/libnsspem.so 7f79aeb59000-7f79aebe5000 r-xp 00000000 fd:00 1708690 /usr/lib64/libsqlite3.so.0.8.6 7f79aebe5000-7f79aede4000 ---p 0008c000 fd:00 1708690 /usr/lib64/libsqlite3.so.0.8.6 7f79aede4000-7f79aede8000 rw-p 0008b000 fd:00 1708690 /usr/lib64/libsqlite3.so.0.8.6 7f79aede8000-7f79aee24000 r-xp 00000000 fd:00 1706243 /usr/lib64/libsoftokn3.so 7f79aee24000-7f79af024000 ---p 0003c000 fd:00 1706243 /usr/lib64/libsoftokn3.so 7f79af024000-7f79af026000 rw-p 0003c000 fd:00 1706243 /usr/lib64/libsoftokn3.so 7f79af026000-7f79af027000 ---p 00000000 00:00 0 7f79af027000-7f79af827000 rw-p 00000000 00:00 0 7f79af827000-7f79af828000 ---p 00000000 00:00 0 7f79af828000-7f79b0028000 rw-p 00000000 00:00 0 7f79b0028000-7f79b00e2000 rw-s 00000000 fd:00 919129 /var/lib/ldap/__db.005 7f79b00e2000-7f79b0322000 rw-s 00000000 fd:00 919128 /var/lib/ldap/__db.004 7f79b0322000-7f79c4324000 rw-s 00000000 fd:00 919125 /var/lib/ldap/__db.003 7f79c4324000-7f79c4bd2000 rw-s 00000000 fd:00 918259 /var/lib/ldap/__db.002 7f79c4bd2000-7f79c4bd6000 r-xp 00000000 fd:00 1705113 /usr/lib64/sasl2/libanonymous.so.2.0.23 7f79c4bd6000-7f79c4dd5000 ---p 00004000 fd:00 1705113 /usr/lib64/sasl2/libanonymous.so.2.0.23 7f79c4dd5000-7f79c4dd6000 rw-p 00003000 fd:00 1705113 /usr/lib64/sasl2/libanonymous.so.2.0.23 7f79c4dd6000-7f79c4ddb000 r-xp 00000000 fd:00 1705116 /usr/lib64/sasl2/libsasldb.so.2.0.23 7f79c4ddb000-7f79c4fda000 ---p 00005000 fd:00 1705116 /usr/lib64/sasl2/libsasldb.so.2.0.23 7f79c4fda000-7f79c4fdb000 rw-p 00004000 fd:00 1705116 /usr/lib64/sasl2/libsasldb.so.2.0.23 7f79c4fdb000-7f79c4fdf000 r-xp 00000000 fd:00 1710213 /usr/lib64/sasl2/libplain.so.2.0.23 7f79c4fdf000-7f79c51de000 ---p 00004000 fd:00 1710213 /usr/lib64/sasl2/libplain.so.2.0.23 7f79c51de000-7f79c51df000 rw-p 00003000 fd:00 1710213 /usr/lib64/sasl2/libplain.so.2.0.23 7f79c51df000-7f79c51e3000 r-xp 00000000 fd:00 1710210 /usr/lib64/sasl2/liblogin.so.2.0.23 7f79c51e3000-7f79c53e2000 ---p 00004000 fd:00 1710210 /usr/lib64/sasl2/liblogin.so.2.0.23 7f79c53e2000-7f79c53e3000 rw-p 00003000 fd:00 1710210 /usr/lib64/sasl2/liblogin.so.2.0.23 7f79c53e3000-7f79c53e8000 r-xp 00000000 fd:00 1572890 /lib64/libnss_dns-2.12.so 7f79c53e8000-7f79c55e7000 ---p 00005000 fd:00 1572890 /lib64/libnss_dns-2.12.so 7f79c55e7000-7f79c55e8000 r--p 00004000 fd:00 1572890 /lib64/libnss_dns-2.12.so 7f79c55e8000-7f79c55e9000 rw-p 00005000 fd:00 1572890 /lib64/libnss_dns-2.12.so 7f79c55e9000-7f79c55f5000 r-xp 00000000 fd:00 1573202 /lib64/libnss_files-2.12.so 7f79c55f5000-7f79c57f5000 ---p 0000c000 fd:00 1573202 /lib64/libnss_files-2.12.so 7f79c57f5000-7f79c57f6000 r--p 0000c000 fd:00 1573202 /lib64/libnss_files-2.12.so 7f79c57f6000-7f79c57f7000 rw-p 0000d000 fd:00 1573202 /lib64/libnss_files-2.12.so 7f79c57f7000-7f79c580c000 r-xp 00000000 fd:00 1573233 /lib64/libz.so.1.2.3 7f79c580c000-7f79c5a0b000 ---p 00015000 fd:00 1573233 /lib64/libz.so.1.2.3 7f79c5a0b000-7f79c5a0c000 rw-p 00014000 fd:00 1573233 /lib64/libz.so.1.2.3 7f79c5a0c000-7f79c5a69000 r-xp 00000000 fd:00 1572935 /lib64/libfreebl3.soAborted

1 0

Re: (ITS#7041) Slapcat exporting bad data?
by Pierangelo Masarati 12 Sep '11

12 Sep '11

The value you see loginEmail:: IGpvY2tleTc1QGhvdG1haWwuY29t is $ echo -n 'IGpvY2tleTc1QGhvdG1haWwuY29t' | base64 -d && echo "" jockey75(a)hotmail.com (note the leading space). I suspect garbage in-garbage out, where LDAP browser is probably hiding garbage by trimming the leading space. You should check with ldapsearch(1) instead. Looks like incorrect data rather than a bug in slapcat(8). p.

1 0

Re: (ITS#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by Kurt＠OpenLDAP.org 12 Sep '11

12 Sep '11

I note that third-party patch submissions cannot be accepted per our IPR policies. The original author is required to submit their own patches. -- Kurt

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2011