Re: (ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match
by Jason_Haar＠trimble.com
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">
<font face="Liberation Sans">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.<br>
<br>
So "-Z" works as I had hoped - excellent<br>
<br>
Thanks!<br>
<br>
Jason<br>
</font><br>
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>
<!-- Converted from text/plain format -->
<br>
<p><font size="2">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:<br>
<br>
> Full_Name: Jason Haar<br>
> Version: 2.4.21<br>
> OS: Fedora<br>
> URL: <a moz-do-not-send="true"
href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a><br>
> Submission from: (NULL) (222.154.246.214)<br>
><br>
><br>
> As you know, LDAP passwords are sent in cleartext unless
TLS or SASL are used.<br>
<br>
Depending on TLS cipher suites and SASL mechnanism choice, of
course.<br>
<br>
And you shouldn't be using a cleartext mechanism unless you've
first authenticated the server.<br>
<br>
><br>
> However, "ldapsearch -Z" will fall-back onto cleartext if
any form of TLS error<br>
> occurs, even the non-fatal "TLS: hostname does not match
CN in peer certificate"<br>
> error.<br>
<br>
Actually, ldapsearch(1) does not fall back into cleartext in
this case. The OpenLDAP library, and most servers, wisely
don't support stop TLS.<br>
<br>
What ldapsearch(1) does is, if told to check certs (the
default) and they are bad, is to terminate the session and
exit.<br>
><br>
> i.e. TLS is attempted, the hostname doesn't match, so
ldapsearch tries again not<br>
> using TLS!<br>
<br>
No it doesn't.<br>
<br>
><br>
> This seems wasteful to me. It is still *more secure* to
continue the encrypted<br>
> TLS session than to fallback onto cleartext.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Now, if you really want to do that, just tell ldapsearch(1)
not to do cert checks.<br>
<br>
<br>
> Web browsers are a good example of<br>
> this: if you connect to a self-signed https site, you can
choose to continue -<br>
> as untrusted https is still secured against other
attackers.<br>
<br>
And some browsers are stupid enough to do basic authentication
without first authenticating the server.<br>
><br>
> If a user wants to guarantee the trustworthiness of their
ldapsearch session,<br>
> they can use "-ZZ" to achieve that - but I can't see any
reason to stop people<br>
> using "-Z" if they want to?<br>
<br>
Nothing stops those who don't want cert checks from disabling
them.<br>
<br>
> (I'm using ldapsearch to dump Active Directory LDAP data
via the DNS round-robin<br>
> entry for the domain name: as such the LDAP host *never*
matches the hostname<br>
> DNS round-robin gives back - and I don't care - I just
don't want the network<br>
> group sniffing my password ;-)<br>
<br>
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).<br>
<br>
-- Kurt<br>
</font>
</p>
</blockquote>
<br>
<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--
12 years
Re: (ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match
by kurt＠OpenLDAP.org
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
12 years
(ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match
by Jason_Haar＠trimble.com
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 ;-)
12 years
make error for signal.c
by Ropp, Gary
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
12 years
Re: (ITS#7044) objectIdentifier not usable for reference in objectClass' MUST or MAY clause
by hyc＠symas.com
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/
12 years
Re: (ITS#7043) double free or corruption error
by hyc＠symas.com
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/
12 years
(ITS#7044) objectIdentifier not usable for reference in objectClass' MUST or MAY clause
by carsten.klein＠axn-software.de
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?
12 years
(ITS#7043) double free or corruption error
by szinski＠richmond.edu
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
12 years
Re: (ITS#7041) Slapcat exporting bad data?
by Pierangelo Masarati
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.
12 years
