- openldap-bugs - openldap.org

(ITS#6607) forwarded bind failure messages cause success
by mbackes＠symas.com 28 Jul '10

28 Jul '10

Full_Name: Matthew Backes Version: RE24 OS: URL: Submission from: (NULL) (76.88.107.46) As noted in http://www.openldap.org/lists/openldap-technical/201004/msg00247.html setting up a chain overlay on the frontend and then configuring ppolicy with ppolicy_forward_updates causes BIND operations with invalid credentials to return success, apparently from the result of the chain operation. This is independent of the value of chain-return-error. WHOAMI reports anonymous after these "successful" BINDs with invalid passwords, so there is no security compromise within the directory itself, however this has (as noted in the above email) catastrophic results for external apps trying to authenticate with BIND.

1 0

(ITS#6606) syncrepl search reply for post-dated cookie
by mbackes＠symas.com 28 Jul '10

28 Jul '10

Full_Name: Matthew Backes Version: RE24 OS: URL: Submission from: (NULL) (76.88.107.46) When replicas try to connect to their provider and supply a cookie generated from a CSN beyond what the provider has, the provider returns success and does nothing. It'd be better to return unwilling-to-perform and squirt out an error indicating that the cookie is in the future. This can happen when the replica is actively receiving changes from the current ppolicy setup or other bug-like situations.

1 0

Re: (ITS#6605) Webmin LDAP User Module Don't Work
by masarati＠aero.polimi.it 28 Jul '10

28 Jul '10

> Full_Name: Andrea Minardi > Version: 2.3.27 > OS: RedHat 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.40.179.242) > > > Webmin's LDAP Users and Groups module stopped working after upgrading from > Webmin 1.400 to webmin 1.510 > > I have been using Webmin's LDAP Users and Groups module on my company's > server > to administer users. It was working fine on Webmin 1.400, but after > upgrading I > get the error: > > "Webmin has connected to the LDAP server, but failed to fetch the schema. > Make > sure that access has not been denied in the LDAP Server module." It is not clear what this issue has to do with OpenLDAP software, since the problem appears after upgrading a third party software. Software interoperation issues can be discussed on openldap-technical. This ITS will be closed. p.

1 0

Re: (ITS#6600) pcache overlay should ignore invalid attributes in search requests
by masarati＠aero.polimi.it 27 Jul '10

27 Jul '10

> Indeed, looking at it with your comments, definitely overkill. I meant > to ask about this approach in the bug description but forgot, sorry. > > Here is a simpler patch which works the same for my tests: > ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100727.patch Hi. Your patch still looks a bit problematic to me. I'm not sure I understood the issue, since it doesn't work for me without further modifications to the code. Suppose I'm searching with a filter that is related to the pcache attrset "cn uid", and my search lists the attributes cn uid undefined what you're trying to accomplish is that this search behaves as if one only requested cn uid right? Well, in this case (at least in HEAD code, I didn't check in re24 yet) it does not work, because all the tests you add work fine, but later the expected attrset will not be matched because the attribute name "undefined" will still be looked for inside the attribute set. You need to add a check that does not look for attributes for which no an_desc was found. However, this case also matches wildcards '*', '+', '1.1'. Tentatively, the "right" patch would be like this <ftp://ftp.openldap.org/incoming/pierangelo-masarati-its6600.1.patch> Please test and report. p.

1 0

Re: (ITS#6599) slapd not responding
by quanah＠zimbra.com 27 Jul '10

27 Jul '10

--On Tuesday, July 27, 2010 7:04 PM +0530 Binoy Joseph <binoy(a)cordys.com> wrote: > > Hi Quanah, > > > Thanks a lot for your reply. > Looks like the issue does not appear with OpenLDAP 2.4.23 and BDB in > Linux. > But somehow the issue still occurs in Windows. > Can you mention which file/issue you are talking about regarding the > locking behavior you mentioned? > Thanks and regards, > Binoy Joseph ITS#6577 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6600) pcache overlay should ignore invalid attributes in search requests
by jonathan＠phillipoux.net 27 Jul '10

27 Jul '10

On 27/07/2010 01:08, masarati(a)aero.polimi.it wrote: >> Full_Name: Jonathan CLARKE >> Version: RE24 >> OS: >> URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100723.patch >> Submission from: (NULL) (80.13.86.63) >> >> >> While checking it's configuration, the pcache overlay verifies each >> configured >> attribute set (pcacheAttrset), to ensure that all attributes in the set >> are >> defined, via slap_str2ad. Given an attribute set with a non-existant >> attribute, >> an error is logged and slapd refuses to start (as expected): >> >> line 117 (pcacheAttrset 0 nonexistantAttr) >> /etc/ldap/slapd.conf: line 117: attribute type undefined. >> >> However, when a search request comes in, the requested attributes list is >> not >> checked by the pcache overlay to ensure that attributes are properly >> defined. In >> effect, slapd just ignores the non-existant attributes, and returns other >> attributes (or behaves as if 1.1 was requested if all requested attributes >> are >> invalid). >> >> This causes pcache's attribute set matching to fail for some requests, >> since it >> counts invalid attributes. If it were to ignore them, configured attribute >> sets >> might match, and successfully cache the search. The patch above implements >> this >> behaviour. Would you consider it for inclusion in OpenLDAP? >> >> I realize this may be considered "repairing bad requests", but sometimes >> one >> can't (easily) control what clients are requesting. Furthermore, it seems >> to >> make sense to have matching behavior all over (since slapd ignores invalid >> requested attributes, pcache should too, IMHO). > > Yours looks like a good catch; however, your patch looks a bit like an > overkill, since the an_desc field of the attribute list that is passed to > get_attr_set() should already be set if the attribute was recognized by > slapd, so you don't need to go through slap_bv2ad() once more. Thanks for your feedback. Indeed, looking at it with your comments, definitely overkill. I meant to ask about this approach in the bug description but forgot, sorry. Here is a simpler patch which works the same for my tests: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100727.patch Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

Re: (ITS#6599) slapd not responding
by binoy＠cordys.com 27 Jul '10

27 Jul '10

--00163628368141a7d5048c5e92b6 Content-Type: text/plain; charset=ISO-8859-1 Hi Quanah, Thanks a lot for your reply. Looks like the issue does not appear with OpenLDAP 2.4.23 and BDB in Linux. But somehow the issue still occurs in Windows. Can you mention which file/issue you are talking about regarding the locking behavior you mentioned? Thanks and regards, Binoy Joseph On Mon, Jul 26, 2010 at 9:18 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Friday, July 23, 2010 1:13 PM +0000 binoy(a)cordys.com wrote: > > Full_Name: Binoy Joseph >> Version: 2.4.21 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (210.210.79.19) >> > > Can you reproduce this with OpenLDAP 2.4.23? There was a change in locking > behavior introduced in 2.4.21 that was backed out in 2.4.23. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > --00163628368141a7d5048c5e92b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hi Quanah,</div><div><br></div><div>Thanks a lot for your reply.</div>= <div>Looks like the issue does not appear with OpenLDAP 2.4.23 and BDB in L= inux.</div><div>But somehow the issue still occurs in Windows.</div><div> Can you mention which file/issue you are talking about regarding the lockin= g behavior you mentioned?</div><br clear=3D"all">Thanks and regards,<div>Bi= noy Joseph<br> <br><br><div class=3D"gmail_quote">On Mon, Jul 26, 2010 at 9:18 PM, Quanah = Gibson-Mount <span dir=3D"ltr"><<a href=3D"mailto:quanah@zimbra.com">qua= nah(a)zimbra.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> --On Friday, July 23, 2010 1:13 PM +0000 <a href=3D"mailto:binoy@cordys.com= " target=3D"_blank">binoy(a)cordys.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Binoy Joseph<br> Version: 2.4.21<br> OS: Linux<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a><br> Submission from: (NULL) (210.210.79.19)<br> </blockquote> <br> Can you reproduce this with OpenLDAP 2.4.23? =A0There was a change in locki= ng behavior introduced in 2.4.21 that was backed out in 2.4.23.<br> <br> --Quanah<br><font color=3D"#888888"> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Principal Software Engineer<br> Zimbra, Inc<br> --------------------<br> Zimbra :: =A0the leader in open source messaging and collaboration<br> </font></blockquote></div><br></div> --00163628368141a7d5048c5e92b6--

1 0

(ITS#6605) Webmin LDAP User Module Don't Work
by andrea.minardi＠port.ravenna.it 27 Jul '10

27 Jul '10

Full_Name: Andrea Minardi Version: 2.3.27 OS: RedHat 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.40.179.242) Webmin's LDAP Users and Groups module stopped working after upgrading from Webmin 1.400 to webmin 1.510 I have been using Webmin's LDAP Users and Groups module on my company's server to administer users. It was working fine on Webmin 1.400, but after upgrading I get the error: "Webmin has connected to the LDAP server, but failed to fetch the schema. Make sure that access has not been denied in the LDAP Server module."

1 0

(ITS#6604) nssov build error
by mhardin＠symas.com 27 Jul '10

27 Jul '10

Full_Name: Matt Hardin Version: 2.4.23 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (184.11.32.102) nssov.c doesn't compile correctly on systems that don't have a getpeereid function because it doesn't use the LUTIL_GETPEEREID macro. The following patch corrects this. --- nssov.c.orig Mon Jul 26 19:50:47 2010 +++ nssov.c Mon Jul 26 19:32:15 2010 @@ -260,9 +260,15 @@ uid_t uid; gid_t gid; char authid[sizeof("gidNumber=4294967295+uidNumber=424967295,cn=peercred,cn=external,cn=auth")]; +#ifdef LDAP_PF_LOCAL_SENDMSG + char peerbuf[8]; + struct berval peerbv = BER_BVNULL; + peerbv.bv_val = peerbuf; + peerbv.bv_len = sizeof( peerbuf ); +#endif /* log connection */ - if (lutil_getpeereid(sock,&uid,&gid)) + if( LUTIL_GETPEEREID( sock, &uid, &gid, &peerbv )) Debug( LDAP_DEBUG_TRACE,"nssov: connection from unknown client: %s\n",strerror(errno),0,0); else Debug( LDAP_DEBUG_TRACE,"nssov: connection from uid=%d gid=%d\n",

1 0

(ITS#6603) EAGAIN, EWOULDBLOCK occasionally used without checking #ifdef
by masarati＠aero.polimi.it 27 Jul '10

27 Jul '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.243) Submitted by: ando At least in libldap and liblber EAGAIN and EWOULDBLOCK are occasionally used without checking whether they are defined or not. Either the checks should be removed, counting on the fact that these error codes are always defined, or they should be used consistently.

1 0

Re: (ITS#6600) pcache overlay should ignore invalid attributes in search requests
by masarati＠aero.polimi.it 27 Jul '10

27 Jul '10

> Full_Name: Jonathan CLARKE > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100723.patch > Submission from: (NULL) (80.13.86.63) > > > While checking it's configuration, the pcache overlay verifies each > configured > attribute set (pcacheAttrset), to ensure that all attributes in the set > are > defined, via slap_str2ad. Given an attribute set with a non-existant > attribute, > an error is logged and slapd refuses to start (as expected): > > line 117 (pcacheAttrset 0 nonexistantAttr) > /etc/ldap/slapd.conf: line 117: attribute type undefined. > > However, when a search request comes in, the requested attributes list is > not > checked by the pcache overlay to ensure that attributes are properly > defined. In > effect, slapd just ignores the non-existant attributes, and returns other > attributes (or behaves as if 1.1 was requested if all requested attributes > are > invalid). > > This causes pcache's attribute set matching to fail for some requests, > since it > counts invalid attributes. If it were to ignore them, configured attribute > sets > might match, and successfully cache the search. The patch above implements > this > behaviour. Would you consider it for inclusion in OpenLDAP? > > I realize this may be considered "repairing bad requests", but sometimes > one > can't (easily) control what clients are requesting. Furthermore, it seems > to > make sense to have matching behavior all over (since slapd ignores invalid > requested attributes, pcache should too, IMHO). Yours looks like a good catch; however, your patch looks a bit like an overkill, since the an_desc field of the attribute list that is passed to get_attr_set() should already be set if the attribute was recognized by slapd, so you don't need to go through slap_bv2ad() once more. p.

1 0

(ITS#6602) ldap_chase_v3referrals() modifies ld_nextref_proc
by masarati＠aero.polimi.it 27 Jul '10

27 Jul '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.243) Submitted by: ando A fix is coming.

1 0

(ITS#6601) Document ldap_set_urllist_proc()
by masarati＠aero.polimi.it 27 Jul '10

27 Jul '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.243) Submitted by: ando ldap_set_urllist_proc() is not documented; a patch for ldap_open.3 is coming. p.

1 0

Re: (ITS#6599) slapd not responding
by quanah＠zimbra.com 26 Jul '10

26 Jul '10

--On Friday, July 23, 2010 1:13 PM +0000 binoy(a)cordys.com wrote: > Full_Name: Binoy Joseph > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (210.210.79.19) Can you reproduce this with OpenLDAP 2.4.23? There was a change in locking behavior introduced in 2.4.21 that was backed out in 2.4.23. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by h.b.furuseth＠usit.uio.no 26 Jul '10

26 Jul '10

quanah(a)zimbra.com writes: >>> Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is >>> undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY >>> somewhere is defined to expand to an expression involving a (long) cast. >> >> Apprently so. >> >> <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg785259. >> html> > > Fixed by debian. Which is nice, but doesn't help with older debian versions. I don't see what's wrong with changing our #elif to #elif defined like you originally suggested, though I remember there was some confused #elif discussion earlier. -- Hallvard

1 0

(ITS#6600) pcache overlay should ignore invalid attributes in search requests
by jonathan＠phillipoux.net 23 Jul '10

23 Jul '10

Full_Name: Jonathan CLARKE Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100723.patch Submission from: (NULL) (80.13.86.63) While checking it's configuration, the pcache overlay verifies each configured attribute set (pcacheAttrset), to ensure that all attributes in the set are defined, via slap_str2ad. Given an attribute set with a non-existant attribute, an error is logged and slapd refuses to start (as expected): line 117 (pcacheAttrset 0 nonexistantAttr) /etc/ldap/slapd.conf: line 117: attribute type undefined. However, when a search request comes in, the requested attributes list is not checked by the pcache overlay to ensure that attributes are properly defined. In effect, slapd just ignores the non-existant attributes, and returns other attributes (or behaves as if 1.1 was requested if all requested attributes are invalid). This causes pcache's attribute set matching to fail for some requests, since it counts invalid attributes. If it were to ignore them, configured attribute sets might match, and successfully cache the search. The patch above implements this behaviour. Would you consider it for inclusion in OpenLDAP? I realize this may be considered "repairing bad requests", but sometimes one can't (easily) control what clients are requesting. Furthermore, it seems to make sense to have matching behavior all over (since slapd ignores invalid requested attributes, pcache should too, IMHO).

1 0

(ITS#6599) slapd not responding
by binoy＠cordys.com 23 Jul '10

23 Jul '10

Full_Name: Binoy Joseph Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.210.79.19) I run OpenLDAP 2.4.21 configured to bdb on Windows and Linux. We run some applications on top of our application framework which in turn is connected to OpenLDAP via JLDAP. We list children of 'cn=soap nodes' (search LDAP) very often as shown in the DIT below. I wrote a test case to create soapnode, soapproc, connectionpoint and then delete them one after the other, ie I create set1, delete set1, create set2, delete set2... Note that list children of 'cn=soap nodes' happen in parallel as mentioned above. Randomly but very consistently, suddenly we face an LDAP not responding issue. When I connect via an LDAP Explorer, I am able to see and expand most of the LDAP entries, except the 'cn=soap nodes' as shown in the DIT below, which says LDAP query did not return indefinitely. CPU: slapd shoots to 50% in Windows and 100% in Linux. Then I have to kill slapd and start again. This does not happen in OpenLDAP 2.4.16. After upgrading to 2.4.21 this started happening. When I switched to hdb, this does not occur in Linux, but continues to happen in Windows. This also looks very similar to http://www.openldap.org/its/index.cgi?findid=6322, Subject: slapd suddenly stops working, and starts using 100% CPU. o=org1 | +-cn=soap nodes | +-cn=soapnode1 | | | +cn=soapproc1 | | | +cn=connectionpoint1 | +-cn=soapnode2 . . Thanks and regards, Binoy Joseph

1 0

Re: (ITS#6489) Incomplete Master/Slave Replication
by frank.offermanns＠caseris.de 23 Jul '10

23 Jul '10

Hello Quanah, thanks for your info. I compiled OpenLDAP 2.4.23 and BDB 4.8.30, but unfortunately the problem still persists. I added 10000 Users added and: with RefreshAndPersist in 136 users at least one attribute was missing. with RefreshOnly in 34 users at least one attribute was missing. In my post in March I said, that with accesslog I do not have this problem. This is not completely true. Meanwhile (also with 2.4.21) I found out that with accesslog I also have this problem, but less frequentely. So with about 40000 users added I had only about 1 or 2 attributes missing. With the new version I added 10000, 20000 and 80000 users without a single problem. So I am not sure, if this problem still persist with accesslog, but with RefreshAndPersist and RefreshOnly there is definitely still a problem. Due to the fact that no one else complains about this, maybe this problem is Windows only? Or is there someone else who also has this problem? If you are interested I could provide you my windows test-application. With this the problem can be reproduced in a few minutes. Let me know if I should send you this program. Thanks a lot so far. Best regards, Frank Offermanns > > > Full_Name: Frank Offermanns > > Version: 2.4.21 > > OS: Windwos > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (217.6.189.242) > > > > > > I am running LDAP from Head with BDB 4.8.26 as backend on windows. I am > > testing master/slave replication while adding 10000 users with 10 filled > > attributes. I am not using a specific time synchronization. Standard > > windows time synchronization in domains is active. But as far as I > > understood, a microsecond time synchronisation is only needed for > > master-master, which I am not testing. > > BDB 4.8.26 is known problematic. Please use BDB 4.8.30, and OpenLDAP > 2.4.23, and report back if you still have issues. > > Thanks! > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6489) Incomplete Master/Slave Replication
by quanah＠zimbra.com 22 Jul '10

22 Jul '10

--On Tuesday, March 09, 2010 12:23 PM +0000 Frank.Offermanns(a)caseris.de wrote: > Full_Name: Frank Offermanns > Version: 2.4.21 > OS: Windwos > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.6.189.242) > > > I am running LDAP from Head with BDB 4.8.26 as backend on windows. I am > testing master/slave replication while adding 10000 users with 10 filled > attributes. I am not using a specific time synchronization. Standard > windows time synchronization in domains is active. But as far as I > understood, a microsecond time synchronisation is only needed for > master-master, which I am not testing. BDB 4.8.26 is known problematic. Please use BDB 4.8.30, and OpenLDAP 2.4.23, and report back if you still have issues. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6476) Failure to delete entry with multi-master replication
by quanah＠zimbra.com 22 Jul '10

22 Jul '10

--On Wednesday, February 17, 2010 1:05 PM +0000 worganc(a)avaya.com wrote: > Full_Name: Craig Worgan > Version: 2.4.21 > OS: RedHat Enterprise Linux 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.11.182.86) Hi Craig, Are you able to reproduce this with OpenLDAP 2.4.23? There have been some fixes around deletes since 2.4.21, and an issue that was introduced in 2.4.21 specific to cached objects as well. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by quanah＠zimbra.com 22 Jul '10

22 Jul '10

--On Tuesday, May 25, 2010 6:37 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, April 30, 2010 1:23 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> quanah(a)zimbra.com writes: >>> Actually, the issue seems to be name changes in the header files under >>> BSD. This causes TIOCNOTTY to end up being undefined. >> >> That would not give the error message shown in >> <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg776021. >> html>: >> >> build/buildd-openldap_2.4.21-1-kfreebsd-amd64-VWAqZY/openldap-2.4.21/libr >> aries/liblutil/detach.c:131:7: error: missing binary operator before >> token "long" >> >> Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is >> undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY >> somewhere is defined to expand to an expression involving a (long) cast. > > Apprently so. > > <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg785259. > html> Fixed by debian. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Fwd: Re: (ITS#6590) slaptest ignores slapd.conf's dbconfig statement during conversion into cn=config
by daniel＠pluta.biz 22 Jul '10

22 Jul '10

Hi Howard, > ==> I'm pretty sure there is a bug in HEAD (either in CVS or in my > HEAD). ;-) This ITS can be closed - the bug was in my head rather than in CVS head (background information: unresolved cvs update conflicts). I'm sorry for the inconveniences! Best regards, Daniel

1 0

Re: (ITS#6590) slaptest ignores slapd.conf's dbconfig statement during conversion into cn=config
by daniel＠pluta.biz 22 Jul '10

22 Jul '10

On 07/21/2010 10:53 PM, Howard Chu wrote: > daniel(a)pluta.biz wrote: >> Full_Name: Daniel Pluta >> Version: HEAD >> OS: Lnx >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4ca0:0:f000:4877:9270:3ab1:2849) >> >> >> slaptest -f -F ignores slapd.conf (bdb/hdb convenience) dbconfig >> settings. >> >> Steps to reproduce: >> >> 1.) cat> slapd.conf<<EOF >> include /tmp/openldap/etc/openldap/schema/core.schema >> pidfile /tmp/openldap/var/run/slapd.pid >> argsfile /tmp/openldap/var/run/slapd.args >> database hdb >> dbconfig set_cachesize 0 1048576 0 >> dbconfig set_lg_bsize 2097152 >> suffix "dc=my-domain,dc=com" >> rootdn "cn=Manager,dc=my-domain,dc=com" >> rootpw secret >> directory /tmp/openldap/var/openldap-data >> index objectClass eq >> EOF >> >> 2.) convert slapd.conf into cn=config: >> mkdir slapd.d&& slaptest -f slapd.conf -F slapd.d >> >> 3.) search slapd.d directory for "olcdbconfig" attribute values: >> grep -R -i olcDbConfig slapd.d/ >> >> the string "olcDbConfig" cannot be found (only in schema definition)... >> > I'm unable to reproduce this issue; the conversion works for me: > > violino:~/OD/hobj/tests> ../servers/slapd/slapd -Ttest -f > testrun/slapd.1.conf -F testrun/slapd.d -d -1 > violino:~/OD/hobj/tests> ../servers/slapd/slapd -Tc -F testrun/slapd.d > -n0 | less > > dn: olcDatabase={1}bdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcBdbConfig > olcDatabase: {1}bdb > olcSuffix: dc=example,dc=com > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=Manager,dc=example,dc=com > olcRootPW:: c2VjcmV0 > olcSyncUseSubentry: FALSE > olcMonitoring: TRUE > olcDbDirectory: /home/hyc/OD/hobj/tests/testrun/db.1.a > olcDbCacheSize: 1000 > olcDbCheckpoint: 1024 5 > olcDbConfig: {0}set_lg_bsize 2097152 > olcDbNoSync: FALSE > olcDbDirtyRead: FALSE > olcDbIDLcacheSize: 0 > olcDbIndex: objectClass eq > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq,sub > olcDbIndex: sn pres,eq,sub > olcDbLinearIndex: FALSE > olcDbMode: 0600 > olcDbSearchStack: 16 > olcDbShmKey: 0 > olcDbCacheFree: 1 > olcDbDNcacheSize: 0 > structuralObjectClass: olcBdbConfig > entryUUID: 8a31068c-449d-491c-9ddf-4fb817dad065 > creatorsName: cn=config > createTimestamp: 20100721204954Z > entryCSN: 20100721204954.041390Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20100721204954Z > Many thanks Howard for your reply. hmmm, sounds like some kind of deadlock to me: you cannot reproduce my and I cannot re-reproduce your results. All differences I can currently see: I'm using "hdb" and I use "grep -r -i 'olcDbConfig' slapd.d/" to test whether olcDbConfig does exist in any file below slapd.d. As the contents of an existing DB_CONFIG file (within the database-dir) will be converted correctly into olcDbConfig here, are you sure you had no "DB_CONFIG" file in your database directory? Could you please provide me the (original) slapd.conf you've used above? Than I would like to reproduce your exact test procedure here. ==> I'm pretty sure there is a bug in HEAD (either in CVS or in my HEAD). ;-)

1 0

Re: (ITS#6585) close is called from dap_unbind_s with fd = -1
by hyc＠symas.com 21 Jul '10

21 Jul '10

asifiqbal.desai(a)gmail.com wrote: > Full_Name: Asif Iqbal Desai > Version: 2.4.16 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.214.64.6) > > > This is a consulation bug for clarification on close() being called from > ldap_unbind_s with fd = 1. > > The application uses ldap client apis for user authentication. > We recently upgraded to use OpenLDAP version 2.4.16 and are getting an > unexpected AIO error issue when ldap user authentication is enabled. > > Investigating further revealed that from ldap_unbind_s ( close(-1) is getting > called. However the close function of solaris libaio does a special handling > when fd< 0 which causes AIO errors. > > The application needs solaris aio support and hence cannot link libc before > libaio. > > Is there any specific reason for close being called with fd = -1 from > ldap_unbind_s. > This issue didnot exist with OpenLDAP 2.3.27. I've checked 2.3.43 and 2.4.23; in both cases ber_int_sb_close() is being called twice on the same sockbuf. I suppose that might be considered a bug, but certainly the behavior has not changed between 2.3 and 2.4. > Following is the stacktrace: > [1] _libaio_close(0xffffffffffffffff, 0x2, 0x1, 0xffffffff7f300200, 0x0, 0x0), > at 0xffffffff7f406a64 > [2] sb_stream_close(0x100151d80, 0x0, 0x0, 0xffffffff7f300200, 0x0, 0x0), at > 0xffffffff7d21eafc > [3] ber_int_sb_close(0x100151d00, 0x0, 0x0, 0xffffffff7f300200, 0x0, 0x0), at > 0xffffffff7d21e160 > [4] ber_sockbuf_free(0x100151d00, 0x1001497d0, 0x1, 0x1, 0xffffffff7dbad2ec, > 0xd), at 0xffffffff7d21cebc > [5] ldap_ld_free(0x100149520, 0x1, 0x0, 0x0, 0x100117020, 0xdc3), at > 0xffffffff7d26a4bc > [6] ldap_unbind_ext(0x100149520, 0x0, 0x0, 0x1001219e0, 0x1001219f8, > 0x100121a00), at 0xffffffff7d26a048 > [7] ldap_unbind_s(0x100149520, 0x1001471d0, 0x100149520, 0xfffffffffffffff2, > 0x0, 0x100117728), at 0xffffffff7d26a55c > ... > ... > > Thanks in Advance, > Asif Iqbal Desai > > -- -- 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#6595) Patch - Mozilla NSS - delay token auth until needed
by hyc＠symas.com 21 Jul '10

21 Jul '10

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-initauthtoken.patch > Submission from: (NULL) (76.113.111.209) > > > The code was doing all of the authentications to all of the tokens during the > init phase. This was causing problems with NSS cert/key clients, prompting for > the cert/key db password, when it isn't needed, since it is only needed to get > private key information. The patch is to just remove the token authentication > during init. The code already authenticates to the token when private key > information is needed e.g. running in TLS/SSL server mode, or using client cert > auth. > > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > Committed to HEAD. -- -- 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#6590) slaptest ignores slapd.conf's dbconfig statement during conversion into cn=config
by hyc＠symas.com 21 Jul '10

21 Jul '10

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: HEAD > OS: Lnx > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4ca0:0:f000:4877:9270:3ab1:2849) > > > slaptest -f -F ignores slapd.conf (bdb/hdb convenience) dbconfig settings. > > Steps to reproduce: > > 1.) cat> slapd.conf<<EOF > include /tmp/openldap/etc/openldap/schema/core.schema > pidfile /tmp/openldap/var/run/slapd.pid > argsfile /tmp/openldap/var/run/slapd.args > database hdb > dbconfig set_cachesize 0 1048576 0 > dbconfig set_lg_bsize 2097152 > suffix "dc=my-domain,dc=com" > rootdn "cn=Manager,dc=my-domain,dc=com" > rootpw secret > directory /tmp/openldap/var/openldap-data > index objectClass eq > EOF > > 2.) convert slapd.conf into cn=config: > mkdir slapd.d&& slaptest -f slapd.conf -F slapd.d > > 3.) search slapd.d directory for "olcdbconfig" attribute values: > grep -R -i olcDbConfig slapd.d/ > > the string "olcDbConfig" cannot be found (only in schema definition)... > I'm unable to reproduce this issue; the conversion works for me: violino:~/OD/hobj/tests> ../servers/slapd/slapd -Ttest -f testrun/slapd.1.conf -F testrun/slapd.d -d -1 violino:~/OD/hobj/tests> ../servers/slapd/slapd -Tc -F testrun/slapd.d -n0 | less dn: olcDatabase={1}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcSuffix: dc=example,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=example,dc=com olcRootPW:: c2VjcmV0 olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: /home/hyc/OD/hobj/tests/testrun/db.1.a olcDbCacheSize: 1000 olcDbCheckpoint: 1024 5 olcDbConfig: {0}set_lg_bsize 2097152 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 8a31068c-449d-491c-9ddf-4fb817dad065 creatorsName: cn=config createTimestamp: 20100721204954Z entryCSN: 20100721204954.041390Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721204954Z -- -- 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#6598) EXOP to return number of children of a (sub)tree
by hyc＠symas.com 21 Jul '10

21 Jul '10

masarati(a)aero.polimi.it wrote: >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: NA >>> OS: NA >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.45.108) >>> >>> >>> It would be extremely useful to have an extended operation that allows >>> querying >>> the number of children of a given (sub)tree, so that one can avoid >>> iterating >>> through the entire subtree to determine this number. >>> >> Might as well ask for the numSubordinates operational attribute to be >> implemented instead, this doesn't seem to merit a new exop. And for >> numSubordinates, see the -devel archives for why we chose not to implement >> it. >> >> In either case, the server still needs to iterate over all entries >> internally, >> and the result has to take ACLs and entry disclosure into account. > > An exop would allow to easily discriminate between intentional and > "catchall" requests, like "+". Moreover, it might make sense to > discriminate at least between subtree and onelevel number of subordinates; > this would require two distinct operational attributes, or a parameter in > the exop. > > I'm not endorsing either solution, I'm just pointing out possible pros and > cons. If you want to be able to distinguish results based on scope then it makes more sense to just define a Search control. Like No-op - count the entries that would be returned, instead of returning them. (And bypassing the sizelimit too, but probably not bypassing timelimit.) -- -- 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#6597 published: SECURITY: ldap service crash while connected AD server reboot
by openldap-its＠OpenLDAP.org 21 Jul '10

21 Jul '10

Private ITS#6597 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6597

1 0

ITS#6593 published: SECURITY: Ldapsearch Error while using Back-NDB
by openldap-its＠OpenLDAP.org 21 Jul '10

21 Jul '10

Private ITS#6593 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6593

1 0

ITS#6594 published: SECURITY: Ldapsearch Error while using Back-NDB
by openldap-its＠OpenLDAP.org 21 Jul '10

21 Jul '10

Private ITS#6594 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6594

1 0

Re: (ITS#6598) EXOP to return number of children of a (sub)tree
by masarati＠aero.polimi.it 21 Jul '10

21 Jul '10

> quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: NA >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.45.108) >> >> >> It would be extremely useful to have an extended operation that allows >> querying >> the number of children of a given (sub)tree, so that one can avoid >> iterating >> through the entire subtree to determine this number. >> > Might as well ask for the numSubordinates operational attribute to be > implemented instead, this doesn't seem to merit a new exop. And for > numSubordinates, see the -devel archives for why we chose not to implement > it. > > In either case, the server still needs to iterate over all entries > internally, > and the result has to take ACLs and entry disclosure into account. An exop would allow to easily discriminate between intentional and "catchall" requests, like "+". Moreover, it might make sense to discriminate at least between subtree and onelevel number of subordinates; this would require two distinct operational attributes, or a parameter in the exop. I'm not endorsing either solution, I'm just pointing out possible pros and cons. p.

1 0

Re: (ITS#6598) EXOP to return number of children of a (sub)tree
by hyc＠symas.com 21 Jul '10

21 Jul '10

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: NA > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > It would be extremely useful to have an extended operation that allows querying > the number of children of a given (sub)tree, so that one can avoid iterating > through the entire subtree to determine this number. > Might as well ask for the numSubordinates operational attribute to be implemented instead, this doesn't seem to merit a new exop. And for numSubordinates, see the -devel archives for why we chose not to implement it. In either case, the server still needs to iterate over all entries internally, and the result has to take ACLs and entry disclosure into account. -- -- 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#6598) EXOP to return number of children of a (sub)tree
by quanah＠zimbra.com 21 Jul '10

21 Jul '10

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) It would be extremely useful to have an extended operation that allows querying the number of children of a given (sub)tree, so that one can avoid iterating through the entire subtree to determine this number.

1 0

(ITS#6595) Patch - Mozilla NSS - delay token auth until needed
by rmeggins＠redhat.com 20 Jul '10

20 Jul '10

Full_Name: Rich Megginson Version: 2.4.23 OS: Fedora URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-initauthtoken.patch Submission from: (NULL) (76.113.111.209) The code was doing all of the authentications to all of the tokens during the init phase. This was causing problems with NSS cert/key clients, prompting for the cert/key db password, when it isn't needed, since it is only needed to get private key information. The patch is to just remove the token authentication during init. The code already authenticates to the token when private key information is needed e.g. running in TLS/SSL server mode, or using client cert auth. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6592) slapadd allows objects with objectClass doublets
by masarati＠aero.polimi.it 20 Jul '10

20 Jul '10

slapd(8) can handle those occurrences. slapadd(8) is intended to load LDIF files generated by slapcat(8), thus presumably consistent. In general, it deals with the most obvious errors. I don't think asking slapadd to perform these checks is a good idea, as it would slow it down without real benefit: if an error is caught, you would need to restart, wasting all the actual write effort. A sanity check tool for unreliable LDIF would probably be more appropriate. p.

1 0

(ITS#6592) slapadd allows objects with objectClass doublets
by kolbjorn.barmen＠uninett.no 20 Jul '10

20 Jul '10

Full_Name: Kolbjørn Barmen Version: 2.4.23 OS: Linux, Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:700:1:0:158:38:62:199) I had problems getting syncrepl working, and it the culpit turned out to be doublets of "objectClass: organizationalRole" for given objects. This seems to not have been a problem with old 2.3.30 with old replication mechanics, but for syncrepl it seems critical. When upgrading from 2.3.30 to 2.4.23 slapcat/slapadd was used. Example from ldif: dn: cn=admin,dc=foo,dc=no objectClass: organizationalRole objectClass: top objectClass: simpleSecurityObject objectClass: organizationalRole ... It would be very helpfull if slapadd could detect such obvious fail in ldif-data and spit a warning (when not using -q at least).

1 0

Re: (ITS#6591) Openldap 2.4.16 with BDB 4.7.25 slapd 200% issue
by quanah＠zimbra.com 20 Jul '10

20 Jul '10

--On Monday, July 19, 2010 10:37 PM +0000 dsbrar16(a)yahoo.com wrote: > Full_Name: Devender Singh > Version: 2.4.16 > OS: RHEL5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (122.180.61.218) The ITS system is for submitting bugs, not asking for help. As I already told you in email, use the openldap-technical(a)openldap.org mailing list for your questions about how to properly use and tune OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6475) SASL OTP and syncrepl
by manu＠netbsd.org 20 Jul '10

20 Jul '10

Daniel Pluta <daniel(a)pluta.biz> wrote: > As I'm not (yet ;-)) an OTP-expert I have not tested any further because > I currently just don't know how to calculate the one-time password based > on the challenge ... skey(1) can do it for you. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

(ITS#6591) Openldap 2.4.16 with BDB 4.7.25 slapd 200% issue
by dsbrar16＠yahoo.com 20 Jul '10

20 Jul '10

Full_Name: Devender Singh Version: 2.4.16 OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.180.61.218) Hi All, I need help for openldap slapd 200% cpu utilization issue. I have configured three openldap servers(2 Masters and 1 Slave). I have configure PEN load balancer for failover setup on 2 master openldap servers.It means application server first of all hit the loadbalancer port and than PEN LB will forwad that request to Master 1 or 2 openldap server. Hardware configuration on all boxes: OS: RHEL5(x86_64) RAM: 2GB Number of CPU: 2(Intel(R) Xeon(R)2.00GHz) Number of BDB databases: 2 Databse1: Number of users : 830000 Number of dns: 830000 Database2: Number of users: 2000 Number of dns: 800000 My Application1 using Databse1 and Application2 using Databse2. Application2 just authenticating the users and store last 10 password history only, It means Application1 is not using openldap too much. In Application2(90% dependent on openldap) every user have 1000+ sub leafs entries. when I want to do major changes(number of leafs write) into this, its got hanged and got socket closed error in application logs and CPU utilization goes 200% and RAM 52%. My DB_CONFIG file is below: # $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/12/18 11:53:27 ghenry Exp $ # Example DB_CONFIG file for use with slapd(8) BDB/HDB databases. # # See the Oracle Berkeley DB documentation # <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_co…> # for detail description of DB_CONFIG syntax and semantics. # # Hints can also be found in the OpenLDAP Software FAQ # <http://www.openldap.org/faq/index.cgi?file=2> # in particular: # <http://www.openldap.org/faq/index.cgi?file=1075> # Note: most DB_CONFIG settings will take effect only upon rebuilding # the DB environment. # one 0.25 GB cache set_cachesize 0 268435456 1 # Data Directory #set_data_dir db # Transaction Log settings set_lg_regionmax 262144 set_lg_bsize 2097152 #set_lg_dir logs # Note: special DB_CONFIG flags are no longer needed for "quick" # slapadd(8) or slapindex(8) access (see their -q option). Please help me here that what I need to do for better performance. Thanks in advance. My contact number is +919650477441

1 0

Re: (ITS#6475) SASL OTP and syncrepl
by daniel＠pluta.biz 19 Jul '10

19 Jul '10

Hi, I've received segmentation faults during some basic SASL OTP testing using CVS HEAD. Below you'll find a small patch (against HEAD) which seems to fix this issue ... Before the patch: root@tingletangle:~/repos/openldap# /usr/local/openldap/bin/ldapsearch -v -Y OTP -U test1 ldap_initialize( <DEFAULT> ) SASL/OTP authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) (<== slapd segfault) After the patch has been applied: root@tingletangle:~/repos/openldap# /usr/local/openldap/bin/ldapsearch -v -Y OTP -U test1 ldap_initialize( <DEFAULT> ) SASL/OTP authentication started Challenge: otp-md5 498 ti6311 ext Please enter your one-time password: huhu ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: (<== slapd still running ;-) ) As I'm not (yet ;-)) an OTP-expert I have not tested any further because I currently just don't know how to calculate the one-time password based on the challenge ... Best regards, Daniel Index: servers/slapd/sasl.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/sasl.c,v retrieving revision 1.274 diff -u -r1.274 sasl.c --- servers/slapd/sasl.c 15 Apr 2010 16:13:54 -0000 1.274 +++ servers/slapd/sasl.c 19 Jul 2010 19:55:11 -0000 @@ -548,7 +548,7 @@ op.o_req_ndn.bv_val = (char *)pr[i].values[0]; } #ifdef SLAP_AUXPROP_DONTUSECOPY - { + if ( slap_dontUseCopy_propnames != NULL ) { struct berval bv; ber_str2bv( &pr[i].name[1], 0, 1, &bv ); for ( j = 0; !BER_BVISNULL( &slap_dontUseCopy_propnames[ j ] ); j++ ) {

1 0

(ITS#6590) slaptest ignores slapd.conf's dbconfig statement during conversion into cn=config
by daniel＠pluta.biz 16 Jul '10

16 Jul '10

Full_Name: Daniel Pluta Version: HEAD OS: Lnx URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4ca0:0:f000:4877:9270:3ab1:2849) slaptest -f -F ignores slapd.conf (bdb/hdb convenience) dbconfig settings. Steps to reproduce: 1.) cat > slapd.conf <<EOF include /tmp/openldap/etc/openldap/schema/core.schema pidfile /tmp/openldap/var/run/slapd.pid argsfile /tmp/openldap/var/run/slapd.args database hdb dbconfig set_cachesize 0 1048576 0 dbconfig set_lg_bsize 2097152 suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /tmp/openldap/var/openldap-data index objectClass eq EOF 2.) convert slapd.conf into cn=config: mkdir slapd.d && slaptest -f slapd.conf -F slapd.d 3.) search slapd.d directory for "olcdbconfig" attribute values: grep -R -i olcDbConfig slapd.d/ the string "olcDbConfig" cannot be found (only in schema definition)...

1 0

ITS#6576
by marco.pizzoli＠gmail.com 15 Jul '10

15 Jul '10

--0016e6de0432b2d346048b6a8223 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see only now that my ITS is in closed state, with the note about the use of grep. My initial request is motivated by a heavy trafficated deployment in which access log files are rotated every 3h and the information about the binddn/ip_src fall often in the rotated file. Worst of this, IBM Unix AIX systems permit LDAP integration using a daemon (secldapclntd) which creates a *permanent* pool of connections againts all ldap servers configured. IBM DB2 v9.5+ permit a native ldap integration and the behaviour is analogous to the AIX one. So, if I need to extract specific information about a binddn/ip I have to follow many files and correlate many informations (conn=3D<number>) For my purposes it would be sufficient an extension to slapo-accesslog permitting me to define a filter on the binddn of the activity. Thanks Marco --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --0016e6de0432b2d346048b6a8223 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see only now that my ITS is in closed state, with the note about the use = of grep.<br><br>My initial request is motivated by a heavy trafficated depl= oyment in which access log files are rotated every 3h and the information a= bout the binddn/ip_src fall often in the rotated file.<br> <br>Worst of this, IBM Unix AIX systems permit LDAP integration using a dae= mon (secldapclntd) which creates a *permanent* pool of connections againts = all ldap servers configured.<br>IBM DB2 v9.5+ permit a native ldap integrat= ion and the behaviour is analogous to the AIX one.<br> <br>So, if I need to extract specific information about a binddn/ip I have = to follow many files and correlate many informations (conn=3D<number>= )<br><br>For my purposes it would be sufficient an extension to slapo-acces= slog permitting me to define a filter on the binddn of the activity.<br> <br>Thanks<br>=A0=A0=A0 Marco<br><br><br clear=3D"all"><br>-- <br>_________= ________________________________<br>Non =E8 forte chi non cade, ma chi cade= ndo ha la forza di rialzarsi.<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ji= m Morrison<br> <div style=3D"visibility: hidden; display: inline;" id=3D"avg_ls_inline_pop= up"></div><style type=3D"text/css">#avg_ls_inline_popup { position:absolut= e; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; = width: 240px; overflow: hidden; word-wrap: break-word; color: black; fo= nt-size: 10px; text-align: left; line-height: 13px;}</style> --0016e6de0432b2d346048b6a8223--

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by rmeggins＠redhat.com 14 Jul '10

14 Jul '10

Howard Chu wrote: > Rich Megginson wrote: >> Howard Chu wrote: >>> Rich Megginson wrote: >>>> Howard Chu wrote: >>>>> rmeggins(a)redhat.com wrote: >>>>>> Full_Name: Rich Megginson >>>>>> Version: 2.4.23 >>>>>> OS: Fedora >>>>>> URL: >>>>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >>>>>> >>>>>> >>>>>> >>>>>> Submission from: (NULL) (76.113.111.209) >>>>>> >>>>>> >>>>>> MozNSS doesn't like self-signed CA certs that are also used for >>>>>> TLS/SSL server certs (such as generated by openssl req -x509) >>>>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>>>>> case >>>>>> so, see if the cert and issuer are the same cert, and allow the >>>>>> use of it (with a warning) >>>>> >>>>> If you checked to see if the issuer is already trusted, I guess the >>>>> patch is OK. >>>>> >>>>> But that aside, MozNSS's behavior sounds correct to me, and our >>>>> documentation says to use explicit CA certs, separate from the server >>>>> cert. Is it really a good idea to break this validation check? >>>> Probably not, but openssl seems to allow it. This provides parity >>>> with >>>> the openssl implementation. >>>> >>>> This issue came up when testing openldap with NSS support in Fedora. >>>> The Fedora package creates a self signed CA cert using openssl req >>>> -x509. This works with openldap+openssl, but fails with >>>> openldap+moznss. >>> >>> In the OpenSSL case, it only succeeds if the cert is configured as >>> both a CA cert and a server cert. I.e., the client must have been >>> configured to trust the cert already. I believe for your patch, it >>> should fail when CERT_FindCertIssuer() returns NULL. No? >> You are correct. I've uploaded a new patch. > > OK, committed. Thanks for the patch. And thank you for your help. > >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714-2…<ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p…> >> >> >> Here is the diff between the two patches: >> 32,34c32 >> < + /* no issuer - warn and >> allow */ >> < + status = SECSuccess; >> < + rc = 0; >> --- >> > + /* no issuer - fail */ >> 36c34 >> < + "TLS: warning: the >> server certificate %s has no issuer - " >> --- >> > + "TLS: error: the >> server certificate %s has no issuer - " >> >>> >>>>> Also, where does this check occur in the main sequence of >>>>> verification >>>>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >>>>> been checked successfully? >>>> Yes. This check occurs in the cert chain processing, which is done >>>> last. >>> >>> OK. >>> >> >> > >

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by hyc＠symas.com 14 Jul '10

14 Jul '10

Rich Megginson wrote: > Howard Chu wrote: >> Rich Megginson wrote: >>> Howard Chu wrote: >>>> rmeggins(a)redhat.com wrote: >>>>> Full_Name: Rich Megginson >>>>> Version: 2.4.23 >>>>> OS: Fedora >>>>> URL: >>>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >>>>> >>>>> >>>>> Submission from: (NULL) (76.113.111.209) >>>>> >>>>> >>>>> MozNSS doesn't like self-signed CA certs that are also used for >>>>> TLS/SSL server certs (such as generated by openssl req -x509) >>>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>>>> case >>>>> so, see if the cert and issuer are the same cert, and allow the >>>>> use of it (with a warning) >>>> >>>> If you checked to see if the issuer is already trusted, I guess the >>>> patch is OK. >>>> >>>> But that aside, MozNSS's behavior sounds correct to me, and our >>>> documentation says to use explicit CA certs, separate from the server >>>> cert. Is it really a good idea to break this validation check? >>> Probably not, but openssl seems to allow it. This provides parity with >>> the openssl implementation. >>> >>> This issue came up when testing openldap with NSS support in Fedora. >>> The Fedora package creates a self signed CA cert using openssl req >>> -x509. This works with openldap+openssl, but fails with >>> openldap+moznss. >> >> In the OpenSSL case, it only succeeds if the cert is configured as >> both a CA cert and a server cert. I.e., the client must have been >> configured to trust the cert already. I believe for your patch, it >> should fail when CERT_FindCertIssuer() returns NULL. No? > You are correct. I've uploaded a new patch. OK, committed. Thanks for the patch. > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714-2…<ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p…> > > Here is the diff between the two patches: > 32,34c32 > < + /* no issuer - warn and allow */ > < + status = SECSuccess; > < + rc = 0; > --- > > + /* no issuer - fail */ > 36c34 > < + "TLS: warning: the > server certificate %s has no issuer - " > --- > > + "TLS: error: the > server certificate %s has no issuer - " > >> >>>> Also, where does this check occur in the main sequence of verification >>>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >>>> been checked successfully? >>> Yes. This check occurs in the cert chain processing, which is done >>> last. >> >> OK. >> > > -- -- 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#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by rmeggins＠redhat.com 14 Jul '10

14 Jul '10

Howard Chu wrote: > Rich Megginson wrote: >> Howard Chu wrote: >>> rmeggins(a)redhat.com wrote: >>>> Full_Name: Rich Megginson >>>> Version: 2.4.23 >>>> OS: Fedora >>>> URL: >>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >>>> >>>> >>>> Submission from: (NULL) (76.113.111.209) >>>> >>>> >>>> MozNSS doesn't like self-signed CA certs that are also used for >>>> TLS/SSL server certs (such as generated by openssl req -x509) >>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>>> case >>>> so, see if the cert and issuer are the same cert, and allow the >>>> use of it (with a warning) >>> >>> If you checked to see if the issuer is already trusted, I guess the >>> patch is OK. >>> >>> But that aside, MozNSS's behavior sounds correct to me, and our >>> documentation says to use explicit CA certs, separate from the server >>> cert. Is it really a good idea to break this validation check? >> Probably not, but openssl seems to allow it. This provides parity with >> the openssl implementation. >> >> This issue came up when testing openldap with NSS support in Fedora. >> The Fedora package creates a self signed CA cert using openssl req >> -x509. This works with openldap+openssl, but fails with >> openldap+moznss. > > In the OpenSSL case, it only succeeds if the cert is configured as > both a CA cert and a server cert. I.e., the client must have been > configured to trust the cert already. I believe for your patch, it > should fail when CERT_FindCertIssuer() returns NULL. No? You are correct. I've uploaded a new patch. URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714-2… <ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p…> Here is the diff between the two patches: 32,34c32 < + /* no issuer - warn and allow */ < + status = SECSuccess; < + rc = 0; --- > + /* no issuer - fail */ 36c34 < + "TLS: warning: the server certificate %s has no issuer - " --- > + "TLS: error: the server certificate %s has no issuer - " > >>> Also, where does this check occur in the main sequence of verification >>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >>> been checked successfully? >> Yes. This check occurs in the cert chain processing, which is done >> last. > > OK. >

1 0

ITS#6570 published: SECURITY: Two OpenLDAP preauth vulnerabilities
by openldap-its＠OpenLDAP.org 14 Jul '10

14 Jul '10

Private ITS#6570 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6570

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by hyc＠symas.com 14 Jul '10

14 Jul '10

Rich Megginson wrote: > Howard Chu wrote: >> rmeggins(a)redhat.com wrote: >>> Full_Name: Rich Megginson >>> Version: 2.4.23 >>> OS: Fedora >>> URL: >>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >>> >>> Submission from: (NULL) (76.113.111.209) >>> >>> >>> MozNSS doesn't like self-signed CA certs that are also used for >>> TLS/SSL server certs (such as generated by openssl req -x509) >>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>> case >>> so, see if the cert and issuer are the same cert, and allow the >>> use of it (with a warning) >> >> If you checked to see if the issuer is already trusted, I guess the >> patch is OK. >> >> But that aside, MozNSS's behavior sounds correct to me, and our >> documentation says to use explicit CA certs, separate from the server >> cert. Is it really a good idea to break this validation check? > Probably not, but openssl seems to allow it. This provides parity with > the openssl implementation. > > This issue came up when testing openldap with NSS support in Fedora. > The Fedora package creates a self signed CA cert using openssl req > -x509. This works with openldap+openssl, but fails with openldap+moznss. In the OpenSSL case, it only succeeds if the cert is configured as both a CA cert and a server cert. I.e., the client must have been configured to trust the cert already. I believe for your patch, it should fail when CERT_FindCertIssuer() returns NULL. No? >> Also, where does this check occur in the main sequence of verification >> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >> been checked successfully? > Yes. This check occurs in the cert chain processing, which is done last. OK. -- -- 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#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by rmeggins＠redhat.com 14 Jul '10

14 Jul '10

Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.23 >> OS: Fedora >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >> >> Submission from: (NULL) (76.113.111.209) >> >> >> MozNSS doesn't like self-signed CA certs that are also used for >> TLS/SSL server certs (such as generated by openssl req -x509) >> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >> case >> so, see if the cert and issuer are the same cert, and allow the >> use of it (with a warning) > > If you checked to see if the issuer is already trusted, I guess the > patch is OK. > > But that aside, MozNSS's behavior sounds correct to me, and our > documentation says to use explicit CA certs, separate from the server > cert. Is it really a good idea to break this validation check? Probably not, but openssl seems to allow it. This provides parity with the openssl implementation. This issue came up when testing openldap with NSS support in Fedora. The Fedora package creates a self signed CA cert using openssl req -x509. This works with openldap+openssl, but fails with openldap+moznss. > > Also, where does this check occur in the main sequence of verification > - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already > been checked successfully? Yes. This check occurs in the cert chain processing, which is done last. > >> This patch file is derived from OpenLDAP Software. All of the >> modifications to OpenLDAP Software represented in the following >> patch(es) were developed by Red Hat. Red Hat has not assigned rights >> and/or interest in this work to any party. I, Rich Megginson am >> authorized by Red Hat, my employer, to release this work under the >> following terms. >> >> Red Hat hereby place the following modifications to OpenLDAP Software >> (and only these modifications) into the public domain. Hence, these >> modifications may be freely used and/or redistributed for any purpose >> with or without attribution and/or other notice. >

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by hyc＠symas.com 14 Jul '10

14 Jul '10

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… > Submission from: (NULL) (76.113.111.209) > > > MozNSS doesn't like self-signed CA certs that are also used for > TLS/SSL server certs (such as generated by openssl req -x509) > CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that case > so, see if the cert and issuer are the same cert, and allow the > use of it (with a warning) If you checked to see if the issuer is already trusted, I guess the patch is OK. But that aside, MozNSS's behavior sounds correct to me, and our documentation says to use explicit CA certs, separate from the server cert. Is it really a good idea to break this validation check? Also, where does this check occur in the main sequence of verification - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already been checked successfully? > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. -- -- 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#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by rmeggins＠redhat.com 14 Jul '10

14 Jul '10

Full_Name: Rich Megginson Version: 2.4.23 OS: Fedora URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… Submission from: (NULL) (76.113.111.209) MozNSS doesn't like self-signed CA certs that are also used for TLS/SSL server certs (such as generated by openssl req -x509) CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that case so, see if the cert and issuer are the same cert, and allow the use of it (with a warning) This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs