- openldap-bugs - openldap.org

(ITS#7050) meta stop at the first unreachable candidate
by victor.gattegno＠gmail.com 23 Sep '11

23 Sep '11

Full_Name: victor gattegno Version: 2.4.26 OS: CentOS 5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.181.196.138) Hello, With OpenLDAP 2.4.26, as soon as a candidate directory is unreachable, other directories are not requested by the proxy ; that problem doesn't occur in 2.4.23. It is described in: http://www.openldap.org/lists/openldap-technical/201108/msg00221.html and there is a complete example in: http://www.openldap.org/lists/openldap-technical/201109/msg00044.html I modified openldap-2.4.26/servers/slapd/back-meta/search.c (lines 192 to 198) as follow, and then the problem is solved. I replaced in OpenLDAP 2.4.26 search.c, (from line 192): switch ( rc ) { case LDAP_SUCCESS: break; case LDAP_UNAVAILABLE: goto down; default: goto other; } by (like it was in 2.4.23): if ( rc != LDAP_SUCCESS ) { goto down; } Here is the diff : 192,195c192 < switch ( rc ) { < case LDAP_SUCCESS: < break; < case LDAP_UNAVAILABLE: --- > if ( rc != LDAP_SUCCESS ) { 197,198d193 < default: < goto other; Rgds.

1 0

(ITS#7049) DEL/LDAP_SYNC_DELETE race touching entryCSN
by ebackes＠symas.com 23 Sep '11

23 Sep '11

Full_Name: Emily Backes Version: 2.4.26 OS: any URL: Submission from: (NULL) (76.88.107.46) Similar to the recent overlay fixes to prevent updating entryCSN/contextCSN on local changes, delete operations can cause inappropriate CSN setting on remote servers. Given a multi-master setup (normal syncrepl tested), so that each server has a serverID set, with no overlays loaded other than syncprov, set up two or more threads of delete operations; three or more seems to most reliably reproduce the problem on the systems I've tested. As the deletes are happening, the server1 side should of course show it's entryCSN updating: dn: dc=example,dc=com contextCSN: 20110923044343.412634Z#000000#001#000000 This should of course be mirrored on the server2 side with contextCSN exactly matching the set of CSN's from the server1 side. Instead, after enough concurrent deletes to hit the race: dn: dc=example,dc=com contextCSN: 20110923044343.412634Z#000000#001#000000 contextCSN: 20110923044349.314803Z#000000#002#000000 This happens even though server2 has never received any local write operations (or indeed any connection other than the syncrepl search from server1 and my searches to retrieve contextCSN). Again, no overlays are loaded. This breaks syncrepl's assumptions and can result in other replication problems as a result of CSN desync. Working on tracing out exactly where it goes awry...

1 0

Re: (ITS#7047) slapd crash on bad indexed translucent
by Pierangelo Masarati 21 Sep '11

21 Sep '11

Can you reproduce with latest release/master? Can you provide a minimal configuration+data that allows to reproduce the issue? p.

1 0

Re: (ITS#7048) Non root binding causes assert
by Pierangelo Masarati 21 Sep '11

21 Sep '11

> Full_Name: Aitor Carrera Please check with latest release (or master code); please upload patches according to <http://www.openldap.org/devel/contributing.html>. p.

1 0

Re: (ITS#7048) Non root binding causes assert
by aitor.carrera＠edosoftfactory.com 21 Sep '11

21 Sep '11

--20cf307abe69d114a404ad78b34e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable With this pacth it is solved, we added a precompiler macro to contribute th= e patch because we are not sure about security issues related this problem. META_BACK_REFCNT_MUST_BE_ZERO_FOR_INVALIDATING_EXPIRED_CONNECTION =3D> It m= ust be defined for solving this issue diff -Naur openldap-2.4.21.orig/servers/slapd/back-meta/conn.c openldap-2.4.21/servers/slapd/back-meta/conn.c --- openldap-2.4.21.orig/servers/slapd/back-meta/conn.c 2011-07-26 13:40:40.989376998 +0200 +++ openldap-2.4.21/servers/slapd/back-meta/conn.c 2011-07-26 13:51:40.537383269 +0200 @@ -1156,6 +1156,9 @@ mc =3D NULL; } else { +#ifdef META_BACK_REFCNT_MUST_BE_ZERO_FOR_INVALIDATING_EXPIRED_CONNECTION + if ( mc->mc_refcnt =3D=3D 0) +#endif if ( ( mi->mi_conn_ttl !=3D 0 && op->o_time > mc->mc_create_time + mi->mi_conn_ttl ) || ( mi->mi_idle_timeout !=3D 0 && op->o_time > mc->mc_time + mi->mi_idle_timeout ) ) { Regards -------------------------------------------------------- Aitor Carrera Hern=E1ndez - Edosoft Factory Telf. +34 828021575 Fax. +34 828066081 Antonio Mar=EDa Manrique 3, Planta 2 - Oficina 6. 35011 Las Palmas de Gran Canaria -------------------------------------------------------- --20cf307abe69d114a404ad78b34e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>With this pacth it is solved, we added a precompiler macro to contribu= te the patch because we are not sure about security issues related this pro= blem.</div><div> </div><div>META_BACK_REFCNT_MUST_BE_ZERO_FOR_INVALIDATI= NG_EXPIRED_CONNECTION =3D> It must be defined for solving this issue</di= v> <div> </div><div> </div><div><pre style= =3D"word-wrap: break-word; white-space: pre-wrap; ">diff -Naur openldap-2.4= .21.orig/servers/slapd/back-meta/conn.c openldap-2.4.21/servers/slapd/back-= meta/conn.c --- openldap-2.4.21.orig/servers/slapd/back-meta/conn.c 2011-07-26 13:40:40= .989376998 +0200 +++ openldap-2.4.21/servers/slapd/back-meta/conn.c 2011-07-26 13:51:40.5373= 83269 +0200 @@ -1156,6 +1156,9 @@ mc =3D NULL; =20 } else { +#ifdef META_BACK_REFCNT_MUST_BE_ZERO_FOR_INVALIDATING_EXPIRED_CONNECTION + if ( mc->mc_refcnt =3D=3D 0) +#endif if ( ( mi->mi_conn_ttl !=3D 0 && op->o_time > mc->= mc_create_time + mi->mi_conn_ttl ) || ( mi->mi_idle_timeout !=3D 0 && op->o_time > mc-&= gt;mc_time + mi->mi_idle_timeout ) ) {</pre><pre style=3D"word-wrap: break-word; white-space: pre-wrap; "><= br></pre><pre style=3D"word-wrap: break-word; white-space: pre-wrap; ">Rega= rds</pre></div><div> </div>--------------------------------------= ------------------ Aitor Carrera Hern=E1ndez - Edosoft Factory Telf. +34 828021575 Fax. = +34 828066081 Antonio Mar=EDa Manrique 3, Planta 2 - Oficina 6. 35011= Las Palmas de Gran Canaria --------------------------------------------= ------------ --20cf307abe69d114a404ad78b34e--

1 0

(ITS#7048) Non root binding causes assert
by aitor.carrera＠edosoftfactory.com 21 Sep '11

21 Sep '11

Full_Name: Aitor Carrera Version: 2.4.21 OS: SLES10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.126.219.248) When we use a non root user to bind, with multiple threads and some concurrent proxies 1 .- In meta_back_bind_op_result method, in back-meta bind.c file the assert "assert( LDAP_BACK_CONN_BINDING( msc ) );" is evaluated to false. 2.- Next, calls meta_back_cancel (bind.c) and then ldap_abandon_ext and other assert is evaluated to false: slapd: sasl.c:74: ldap_sasl_bind: Assertion `ld != ((void *)0)' failed. That crash the slapd.

1 0

Re: (ITS#7027) [PATCH] Implement priority/weigh for DNS SRV records
by james.leddy＠redhat.com 20 Sep '11

20 Sep '11

> In addition, random seed has to be initialized, otherwise the behavior > is predictable. I didn't think it too big of a deal, since it doesn't have to be cryptographically random. I can submit a patch to call srandom() first. > On the other side, I do not think that calling srand() > in libldap is a good idea. The client application should do that. Or > is there any other option? The function ldap_domain2hostlist returns a list of strings, there isn't any weight/prio information for the client to act on. Furthermore the weight prio section was commented out, I figured the library was the right place to do it. The algo specified in rfc2782 is detailed, and specifies a random number should be generated., I didn't want to implement it because it results in sorting once by prio, once by weight instead of one sort that does both. -- James M. Leddy Technical Account Manager Red Hat Inc.

1 0

(ITS#7047) slapd crash on bad indexed translucent
by hugo.monteiro＠fct.unl.pt 20 Sep '11

20 Sep '11

Full_Name: Hugo Monteiro Version: 2.4.23 OS: Debian Squeeze 64bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.136.124.150) Performing a substring query on a locally stored attribute of a translucent database, with only equality index will result on slapd crash. We have a translucent database set up to handle samba attributes and we observed that some client operations would crash slapd (like when performing user enumeration, while changind folder ACLs). The last logged query was "(&(objectClass=sambaGroupMapping)(sambaGroupType=4)(sambaSID=<OUR_DOMAINSID_HERE>*))" As per samba documentation we only had equality index on sambaSID attribute. We have then reconfigured that attribute to use eq,sub,pres indexes, ran slapindex on the database and slapd stopped crashing with that query.

1 0

Re: (ITS#7027) [PATCH] Implement priority/weight for DNS SRV records
by jvcelak＠redhat.com 20 Sep '11

20 Sep '11

On Wednesday 24 August 2011 21:28:03, James Leddy wrote: > on incoming ftp There is a typo in the patch: + hostent_head[hostent_count].priority=priority; -+ hostent_head[hostent_count].weight=priority; ++ hostent_head[hostent_count].weight=weight; + hostent_head[hostent_count].port=port; + strncpy(hostent_head[hostent_count].hostname, host,255); + hostent_count=hostent_count+1; In addition, random seed has to be initialized, otherwise the behavior is predictable. On the other side, I do not think that calling srand() in libldap is a good idea. The client application should do that. Or is there any other option? Jan

1 0

(ITS#7046) OpenLDAP logs nothing at info priority, excessive at debug priority
by nick.urbanik＠optusnet.com.au 20 Sep '11

20 Sep '11

Full_Name: Nick Urbanik Version: 2.3.43-12 and 2.4.23-15 OS: CentOS 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.10.68.69) To my great surprise, OpenLDAP logs nothing at info priority, but excessive amounts at debug priority, even when the loglevel is set to stats. Here are examples of the size of log files holding *nothing* but OpenLDAP stats logging in a production server: # ls -lSr | tail -n4 -rw------- 1 root root 7160148590 Jul 28 10:48 ldap -rw------- 1 root root 24102619198 Jul 26 04:02 ldap.3 -rw------- 1 root root 25034865261 Jul 27 04:02 ldap.2 -rw------- 1 root root 25504838803 Jul 28 04:02 ldap.1 $ bc -ql scale = 6 25504838803 / 2^30 23.753232 In other words, we were getting nearly 24 gigabytes of logging *each* *day*. I raised this in the openldap-technical mailing list: http://www.openldap.org/lists/openldap-technical/201107/msg00205.html but found that this is by design: http://www.openldap.org/lists/openldap-technical/201109/msg00223.html OpenLDAP should log at info priority at least the following: * when it is starting up * when it is shutting down cleanly * any errors, indicating issues that the sys admin should pay attention to * (perhaps): one line for each connection.

1 0

Re: (ITS#7044) objectIdentifier not usable for reference in objectClass' MUST or MAY clause
by c.klein＠tarent.de 19 Sep '11

19 Sep '11

Thanks for the information. Any chance this will ever be implemented? I for my part would rather use the objectIdentifiers than the canonical attribute names.

1 0

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

19 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 19 Sep '11

19 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 19 Sep '11

19 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 19 Sep '11

19 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

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

12 Sep '11

On Monday 12 September 2011 19:00:08, Howard Chu wrote: > Thanks for passing along the report, but I'm not convinced this is a > legitimate issue. Servers that trust each other for replication should > accept each other's TLS certificates. As I see it, if their certs aren't > working in this configuration then their certificates were created with > the wrong usage flags, and this is not an OpenLDAP issue. You are definitely right. But disabling the options still might be useful for some people. Including the author of the patch. I think it is a very simple change which adds some extra bonus to current functionality. Nothing critical and no regressions are likely. It would be great, if you could include the patch even if you do not absolutely agree with disabling the client certificate authentication for replication. -- Jan Včelák Base Operating Systems Brno Red Hat Inc.

1 0

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

12 Sep '11

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20110912-syncrepl-allow-unsetting-o… > Submission from: (NULL) (209.132.186.34) > > > Hello, > > I'm just passing a patch submitted to our bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=734187 > > To sum it up: If tls_cert/tls_key syncrepl options are not specified, server > setting is inherited and used. According to various reports on the Internet, > this is a feature, not a bug. Relying on hearsay "According to various reports on the Internet" is a stupid way to get information, particularly when it's already documented in the slapd.conf(5) and slapd-config(5) manpages. > However it forces a replica to use a client > certificate for authentication, because the tls_cert and tls_key options can not > be disabled. > > The patch allows tls_* options to be disabled, like this: "tls_cert=" > Without the patch, "file not found" error will occur. > The patch is written by the submitter of the bug report - Patrick Monnerat (pm > at datasphere dot ch). Thanks for passing along the report, but I'm not convinced this is a legitimate issue. Servers that trust each other for replication should accept each other's TLS certificates. As I see it, if their certs aren't working in this configuration then their certificates were created with the wrong usage flags, and this is not an OpenLDAP issue. -- -- 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#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by jvcelak＠redhat.com 12 Sep '11

12 Sep '11

Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20110912-syncrepl-allow-unsetting-o… Submission from: (NULL) (209.132.186.34) Hello, I'm just passing a patch submitted to our bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=734187 To sum it up: If tls_cert/tls_key syncrepl options are not specified, server setting is inherited and used. According to various reports on the Internet, this is a feature, not a bug. However it forces a replica to use a client certificate for authentication, because the tls_cert and tls_key options can not be disabled. The patch allows tls_* options to be disabled, like this: "tls_cert=" Without the patch, "file not found" error will occur. The patch is written by the submitter of the bug report - Patrick Monnerat (pm at datasphere dot ch). Jan

1 0

Re: (ITS#6925) [PATCH] Use inet_ntop for server when available
by masarati＠aero.polimi.it 09 Sep '11

09 Sep '11

>> Uploaded as xinli-its6925-110630.patch. > > Sorry, apparently I never received this message. It is not clear why you > conditioned it based on HAVE_GETADDRINFO; this seems to be repeated also > throughout the original code. > > The patch is not fine in slapd/daemon.c (the original code seems to be > broken as > well where inet_ntop(3) is already used), since peeraddr is set by > inet_ntop(3) > to point to the buffer addr[], and is used also when addr[] gets out of > scope > (#ifdef HAVE_TCPD). Fixing. The patch and the fixes are in git's master. In the commit log I forgot to mention that many of those fixes, significantly that for LDAP_CONNECTIONLESS, are blind. Please test and report. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs