- openldap-bugs - openldap.org

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Marco Pizzoli wrote: > Hi, > I downloaded the HEAD repository, compiled and tried the import. Same > problem on the same line. > > I went to see the version of the source accesslog.c and saw this line on top > of it: > /* accesslog.c - log operations for audit/history purposes */ > /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 * > 2011/01/26* 23:23:34 quanah Exp $ */ > > Had I downloaded the wrong repository? Sorry, I overlooked part of your message. Yes, you appear to be using the wrong repository. My commit resulted in accesslog.c 1.115. p.

1 0

Re: ITS#6815
by marco.pizzoli＠gmail.com 01 Feb '11

01 Feb '11

--001636e0a68c56af9b049b3a400d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, yes but not all my clients are so flexible. A helpful usage, in my deploy, would be in populating a database with only BIND operations. By now this is not possible. Thanks Marco Pizzoli On Sun, Jan 30, 2011 at 9:12 PM, <masarati(a)aero.polimi.it> wrote: > > This request is spotted by some ldap clients that I have that every > > 30seconds do a dummy ldap search only to keep alive their connection > > to the ldap server. These searches are frequent and I have many of > > these clients in my deploy, so my accesslog become full of not > > significant entries. > > For this specific purpose, your clients could perform an operation that i= s > not logged; for example, search the rootDSE. > > p. > > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --001636e0a68c56af9b049b3a400d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, yes but not all my clients are so flexible. A helpful usage,= in my deploy, would be in populating a database with only BIND operations.= By now this is not possible. Thanks =A0=A0=A0=A0=A0 Marco Pizzol= i <div class=3D"gmail_quote">On Sun, Jan 30, 2011 at 9:12 PM, <<a href=3D"mailto:masarati@aero.polimi.it">masarati(a)aero.polimi.it<= /a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:= 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left= : 1ex;"> > This request is spotted by some ldap clients that I have that every<br= > > 30seconds do a dummy ldap search only to keep alive their connection<b= r> > to the ldap server. These searches are frequent and I have many of > these clients in my deploy, so my accesslog become full of not > significant entries. For this specific purpose, your clients could perform an operation that is<= br> not logged; for example, search the rootDSE. p. </blockquote></div> -- _______________________= __________________ Non =E8 forte chi non cade, ma chi cadendo ha la forz= a di rialzarsi. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morrison <div style=3D"visibility: hidden; left: -5000px; position: absolute; z-inde= x: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden;= word-wrap: break-word; color: black; font-size: 10px; text-align: left; li= ne-height: 130%;" id=3D"avg_ls_inline_popup"> </div> --001636e0a68c56af9b049b3a400d--

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Marco Pizzoli wrote: > Hi, > I downloaded the HEAD repository, compiled and tried the import. Same > problem on the same line. The fix in HEAD fixes the writing of the accesslog entry; you need to try it with a new search on a fresh database, then a slapcat, then a slapadd. Old databases and LDIFs are corrupted and need to be fixed otherwise (e.g. ldapmodify->replace of the reqAttr without the empty value, which is invalid per LDAPString syntax. p.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by marco.pizzoli＠gmail.com 01 Feb '11

01 Feb '11

--000e0cd29c8c87a456049b38f23c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I downloaded the HEAD repository, compiled and tried the import. Same problem on the same line. I went to see the version of the source accesslog.c and saw this line on to= p of it: /* accesslog.c - log operations for audit/history purposes */ /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 * 2011/01/26* 23:23:34 quanah Exp $ */ Had I downloaded the wrong repository? Thanks Marco Pizzoli On Tue, Feb 1, 2011 at 1:10 PM, Pierangelo Masarati <masarati(a)aero.polimi.i= t > wrote: > Marco Pizzoli wrote: > >> Hi, >> the (same?) problem arises again. >> >> I downloaded the upgraded source, created a new accesslog and today trie= d >> to >> slapcat/drop/slapadd. >> This is the error that I'm encountering: >> >> [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b >> "cn=3Dlog03,dc=3D >> mycorp.it" -l dump_ldap_dblog_20110201.ldif >> .### 17.14% eta 01h17m elapsed 15m56s spd 443= .0 >> k/s str2entry: invalid value for attributeType reqAttr #1 (syntax >> 1.3.6.1.4.1.1466.115.121.1.15) >> slapadd: could not parse entry (line=3D13502606) >> _### 17.14% eta 01h17m elapsed 15m56s spd 330= .0 >> k/s >> Closing DB... >> >> The corrupted entry is: >> >> dn: reqStart=3D20110128141509.000004Z,cn=3Dlog03,dc=3Dmycorp.it >> objectClass: auditSearch >> structuralObjectClass: auditSearch >> reqStart: 20110128141509.000004Z >> reqEnd: 20110128141510.000000Z >> reqType: search >> reqSession: 6521 >> reqAuthzID: cn=3DManager,dc=3Dmyregion,dc=3Dmycorp.it >> reqDN: uid=3Dpe1748,ou=3DPeople,dc=3Dmyregion,dc=3Dmycorp.it >> reqResult: 0 >> reqScope: base >> reqDerefAliases: never >> reqAttrsOnly: FALSE >> reqFilter: (&(objectClass=3D*)) >> reqAttr: * >> reqAttr: >> reqEntries: 1 >> reqTimeLimit: -1 >> reqSizeLimit: 500 >> entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf >> creatorsName: cn=3DManager,cn=3Dlog03,dc=3Dmycorp.it >> createTimestamp: 20110128141510Z >> entryCSN: 20110128141510.000116Z#000000#003#000000 >> modifiersName: cn=3DManager,cn=3Dlog03,dc=3Dmycorp.it >> modifyTimestamp: 20110128141510Z >> > > A fix is in HEAD (ITS#6819); more is coming. Please test. Thanks, p. > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --000e0cd29c8c87a456049b38f23c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I downloaded the HEAD repository, compiled and tried the import. Sam= e problem on the same line. I went to see the version of the source = accesslog.c and saw this line on top of it: /* accesslog.c - log operati= ons for audit/history purposes */ /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 20= 11/01/26 23:23:34 quanah Exp $ */ Had I downloaded the wrong rep= ository? Thanks =A0=A0=A0=A0=A0 Marco Pizzoli <div cla= ss=3D"gmail_quote"> On Tue, Feb 1, 2011 at 1:10 PM, Pierangelo Masarati <<= a href=3D"mailto:masarati@aero.polimi.it">masarati(a)aero.polimi.it</a>></= span> wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt = 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div><div class=3D"h5">Marco Pizzoli wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Hi, the (same?) problem arises again. I downloaded the upgraded source, created a new accesslog and today tried t= o slapcat/drop/slapadd. This is the error that I'm encountering: [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b "cn=3Dl= og03,dc=3D <a href=3D"http://mycorp.it" target=3D"_blank">mycorp.it</a>" -l dump_= ldap_dblog_20110201.ldif .### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 17.14% eta 01h17m elapsed =A0 =A0 = =A0 =A0 =A015m56s spd 443.0 k/s str2entry: invalid value for attributeType reqAttr #1 (syntax 1.3.6.1.4.1.1466.115.121.1.15) slapadd: could not parse entry (line=3D13502606) _### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 17.14% eta 01h17m elapsed =A0 =A0 = =A0 =A0 =A015m56s spd 330.0 k/s Closing DB... The corrupted entry is: dn: reqStart=3D20110128141509.000004Z,cn=3Dlog03,dc=3D<a href=3D"http://myc= orp.it" target=3D"_blank">mycorp.it</a> objectClass: auditSearch structuralObjectClass: auditSearch reqStart: 20110128141509.000004Z reqEnd: 20110128141510.000000Z reqType: search reqSession: 6521 reqAuthzID: cn=3DManager,dc=3Dmyregion,dc=3D<a href=3D"http://mycorp.it" ta= rget=3D"_blank">mycorp.it</a> reqDN: uid=3Dpe1748,ou=3DPeople,dc=3Dmyregion,dc=3D<a href=3D"http://mycorp= .it" target=3D"_blank">mycorp.it</a> reqResult: 0 reqScope: base reqDerefAliases: never reqAttrsOnly: FALSE reqFilter: (&(objectClass=3D*)) reqAttr: * reqAttr: reqEntries: 1 reqTimeLimit: -1 reqSizeLimit: 500 entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf creatorsName: cn=3DManager,cn=3Dlog03,dc=3D<a href=3D"http://mycorp.it" tar= get=3D"_blank">mycorp.it</a> createTimestamp: 20110128141510Z entryCSN: 20110128141510.000116Z#000000#003#000000 modifiersName: cn=3DManager,cn=3Dlog03,dc=3D<a href=3D"http://mycorp.it" ta= rget=3D"_blank">mycorp.it</a> modifyTimestamp: 20110128141510Z </blockquote> </div></div> A fix is in HEAD (ITS#6819); more is coming. =A0Please test. =A0Thanks, p.<= br> </blockquote></div> -- _______________________= __________________ Non =E8 forte chi non cade, ma chi cadendo ha la forz= a di rialzarsi. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morrison <div style=3D"visibility: hidden; left: -5000px; position: absolute; z-inde= x: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden;= word-wrap: break-word; color: black; font-size: 10px; text-align: left; li= ne-height: 130%;" id=3D"avg_ls_inline_popup"> </div> --000e0cd29c8c87a456049b38f23c--

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Marco Pizzoli wrote: > Hi, > the (same?) problem arises again. > > I downloaded the upgraded source, created a new accesslog and today tried to > slapcat/drop/slapadd. > This is the error that I'm encountering: > > [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b "cn=log03,dc= > mycorp.it" -l dump_ldap_dblog_20110201.ldif > .### 17.14% eta 01h17m elapsed 15m56s spd 443.0 > k/s str2entry: invalid value for attributeType reqAttr #1 (syntax > 1.3.6.1.4.1.1466.115.121.1.15) > slapadd: could not parse entry (line=13502606) > _### 17.14% eta 01h17m elapsed 15m56s spd 330.0 > k/s > Closing DB... > > The corrupted entry is: > > dn: reqStart=20110128141509.000004Z,cn=log03,dc=mycorp.it > objectClass: auditSearch > structuralObjectClass: auditSearch > reqStart: 20110128141509.000004Z > reqEnd: 20110128141510.000000Z > reqType: search > reqSession: 6521 > reqAuthzID: cn=Manager,dc=myregion,dc=mycorp.it > reqDN: uid=pe1748,ou=People,dc=myregion,dc=mycorp.it > reqResult: 0 > reqScope: base > reqDerefAliases: never > reqAttrsOnly: FALSE > reqFilter: (&(objectClass=*)) > reqAttr: * > reqAttr: > reqEntries: 1 > reqTimeLimit: -1 > reqSizeLimit: 500 > entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf > creatorsName: cn=Manager,cn=log03,dc=mycorp.it > createTimestamp: 20110128141510Z > entryCSN: 20110128141510.000116Z#000000#003#000000 > modifiersName: cn=Manager,cn=log03,dc=mycorp.it > modifyTimestamp: 20110128141510Z A fix is in HEAD (ITS#6819); more is coming. Please test. Thanks, p.

1 0

(ITS#6819) invalid attributes in search request
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.200) Submitted by: ando As per RFC4511 we ignore unknown attributes in search requests, and we handle special attributes according to RFC 3673 and RFC 4529; however we probably should ignore and discard invalid attributes (i.e. attributes not conforming to section 2.5. of RFC4512). A noteworthy example is that right now slapd accepts "" (the empty string). Although there is no strong motivation for discarding non conforming requests (and, as per RFC 3673 and RFC 4529, the production attributeSelector of Section 4.5.1.8. of RFC 4511 had to be extended, so this code should be updated whenever that production is modified further), I think this change would be in the spirit of OpenLDAP's slapd (i.e. liberal in accepting requests with invalid productions, but strict in not letting them proceed further). One case where an invalid production is causing problems downstream is in accesslog, where the empty string is written as the value of a reqAttr, which is invalid per the syntax of reqAttr which is an LDAPString. As a consequence, a slapcat of such an accesslog entry cannot be reloaded. I am fixing accesslog otherwise, but probably invalid attributeselectors should be filtered out when parsing search requests. p.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Marco Pizzoli wrote: > Hi, > the (same?) problem arises again. > > I downloaded the upgraded source, created a new accesslog and today tried to > slapcat/drop/slapadd. > This is the error that I'm encountering: > > [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b "cn=log03,dc= > mycorp.it" -l dump_ldap_dblog_20110201.ldif > .### 17.14% eta 01h17m elapsed 15m56s spd 443.0 > k/s str2entry: invalid value for attributeType reqAttr #1 (syntax > 1.3.6.1.4.1.1466.115.121.1.15) > slapadd: could not parse entry (line=13502606) > _### 17.14% eta 01h17m elapsed 15m56s spd 330.0 > k/s > Closing DB... > > The corrupted entry is: > > dn: reqStart=20110128141509.000004Z,cn=log03,dc=mycorp.it > objectClass: auditSearch > structuralObjectClass: auditSearch > reqStart: 20110128141509.000004Z > reqEnd: 20110128141510.000000Z > reqType: search > reqSession: 6521 > reqAuthzID: cn=Manager,dc=myregion,dc=mycorp.it > reqDN: uid=pe1748,ou=People,dc=myregion,dc=mycorp.it > reqResult: 0 > reqScope: base > reqDerefAliases: never > reqAttrsOnly: FALSE > reqFilter: (&(objectClass=*)) > reqAttr: * > reqAttr: > reqEntries: 1 > reqTimeLimit: -1 > reqSizeLimit: 500 > entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf > creatorsName: cn=Manager,cn=log03,dc=mycorp.it > createTimestamp: 20110128141510Z > entryCSN: 20110128141510.000116Z#000000#003#000000 > modifiersName: cn=Manager,cn=log03,dc=mycorp.it > modifyTimestamp: 20110128141510Z I've found that a search for '*' does generate a log with only one reqAttr value, reqAttr: * However a search for '*' '' (the empty string) actually generates a log like the one you posted. I'll fix this, but in the meanwhile you should fix your client. p.

1 0

Re: (ITS#6818) back-meta: do not denormalize attrs without equality rule
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

h.b.furuseth(a)usit.uio.no wrote: > masarati(a)aero.polimi.it writes: >> Subject: (ITS#6818) back-meta: do not denormalize attrs without equality rule > > Is this denormalizion a user-visible or internal matter? AFAIK it's about generating a printable form of some normal forms, e.g. UUIDs. It's used very seldom, but for some reasons that bit of code assumed an EQUALITY rule was present, and I ran into that after enabling undefined attr filters to be saved in Filter structures for logging purposes (ava.c 1.53 -> 1.54). I don't think the user needs to be aware of that. p.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by marco.pizzoli＠gmail.com 01 Feb '11

01 Feb '11

--00504502c82c9d7fc8049b363033 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, the (same?) problem arises again. I downloaded the upgraded source, created a new accesslog and today tried t= o slapcat/drop/slapadd. This is the error that I'm encountering: [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b "cn=3Dlog03,= dc=3D mycorp.it" -l dump_ldap_dblog_20110201.ldif .### 17.14% eta 01h17m elapsed 15m56s spd 443.0 k/s str2entry: invalid value for attributeType reqAttr #1 (syntax 1.3.6.1.4.1.1466.115.121.1.15) slapadd: could not parse entry (line=3D13502606) _### 17.14% eta 01h17m elapsed 15m56s spd 330.0 k/s Closing DB... The corrupted entry is: dn: reqStart=3D20110128141509.000004Z,cn=3Dlog03,dc=3Dmycorp.it objectClass: auditSearch structuralObjectClass: auditSearch reqStart: 20110128141509.000004Z reqEnd: 20110128141510.000000Z reqType: search reqSession: 6521 reqAuthzID: cn=3DManager,dc=3Dmyregion,dc=3Dmycorp.it reqDN: uid=3Dpe1748,ou=3DPeople,dc=3Dmyregion,dc=3Dmycorp.it reqResult: 0 reqScope: base reqDerefAliases: never reqAttrsOnly: FALSE reqFilter: (&(objectClass=3D*)) reqAttr: * reqAttr: reqEntries: 1 reqTimeLimit: -1 reqSizeLimit: 500 entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf creatorsName: cn=3DManager,cn=3Dlog03,dc=3Dmycorp.it createTimestamp: 20110128141510Z entryCSN: 20110128141510.000116Z#000000#003#000000 modifiersName: cn=3DManager,cn=3Dlog03,dc=3Dmycorp.it modifyTimestamp: 20110128141510Z Thanks Marco Pizzoli On Sun, Jan 2, 2011 at 4:01 PM, <masarati(a)aero.polimi.it> wrote: > > Full_Name: Marco Pizzoli > > Version: 2.4.23 > > OS: Linux x86_64 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (193.41.84.11) > > > > > > Hi, > > I had a problem with my Accesslog database. > > I was investigating an anomaly that I had and, in doing this, I tried t= o: > > - backup (slapcat) my accesslog db > > - drop the entire db (rm -f alock, *.bdb, log.*, __db*) > > - slapadd the db > > > > In slapadd I obtained this error: > > > > --- BEGIN > > /usr/sbin/slapadd -b "cn=3Dlog,dc=3Dmycorp.it" -l > > /srv/bck/dump_db_log.ldif.20100916 > > . 0.00% eta 08h35m elapsed spd > 90.2 > > k/s > > str2entry: invalid value for attributeType reqControls #0 (syntax > > 1.3.6.1.4.1.4203.666.11.5.3.1) > > slapadd2.4: could not parse entry (line=3D4907) > > - 0.01% eta 05h58m elapsed spd > 205.7 > > k/s > > Closing DB... > > --- END > > > > I went to that line and found this entry: > > > > --- BEGIN > > dn: reqStart=3D20100913065628.000008Z,cn=3Dlog,dc=3Dmycorp.it > > objectClass: auditSearch > > structuralObjectClass: auditSearch > > reqStart: 20100913065628.000008Z > > reqEnd: 20100913065628.000009Z > > reqType: search > > reqSession: 1129 > > reqAuthzID: > > cn=3Dsyncrepl-ldap04,ou=3Dutenze_tecniche_openldap,ou=3DGestori,dc=3Dmy= corp.it > > reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue > > "30440K0103043M7269643N > > > 3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735= 355K2 > > 330303030303023303033233030303030300001PP"} > > reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE} > > reqDN: dc=3Dmycorp.it > > reqResult: 0 > > reqScope: base > > reqDerefAliases: never > > reqAttrsOnly: TRUE > > reqFilter: (objectclass=3D*) > > reqAttr: 1.1 > > reqEntries: 0 > > reqTimeLimit: -1 > > reqSizeLimit: 1 > > entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7 > > creatorsName: cn=3DManager,cn=3Dlog,dc=3Dmycorp.it > > createTimestamp: 20100913065628Z > > entryCSN: 20100913065628.167225Z#000000#003#000000 > > modifiersName: cn=3DManager,cn=3Dlog,dc=3Dmycorp.it > > modifyTimestamp: 20100913065628Z > > --- END > > > > Having produced this ldif using slapcat and not having "touched" the > > environment > > in between could I assume this to be a bug? > > The entry showed is related to an access made by another OL server of m= y > > deployment, which is in mirrormode(=3Dtrue). > > This OL is 2.4.23 with BDB4.8.30. Other OLs are 2.4.22 with BDB4.8.26 > > > > > > I deleted this entry and retried the import. > > Now I have the following error: > > --- BEGIN > > /usr/sbin/slapadd2.4 -b "cn=3Dlog,dc=3Dmycorp.it" -l > > /tmp/dump_db_log.ldif.20100916_Corrected > > " 4.69% eta 01h07m elapsed 03m19s spd > 542.3 > > k/s > > str2entry: invalid value for attributeType reqRespControls #0 (syntax > > 1.3.6.1.4.1.4203.666.11.5.3.1) > > slapadd2.4: could not parse entry (line=3D3099715) > > * 4.70% eta 01h07m elapsed 03m20s spd > 979.8 > > k/s > > Closing DB... > > --- END > > > > The "corrupted" entry is this one: > > > > --- BEGIN > > dn: reqStart=3D20100913093021.000000Z,cn=3Dlog,dc=3Dmycorp.it > > objectClass: auditBind > > structuralObjectClass: auditBind > > reqStart: 20100913093021.000000Z > > reqEnd: 20100913093021.000001Z > > reqType: bind > > reqSession: 2746 > > reqAuthzID: > > reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1} > > reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000"} > > reqDN: uid=3Dpe1597,ou=3DPeople,dc=3Dmycorp.it > > reqResult: 0 > > reqVersion: 3 > > reqMethod: SIMPLE > > entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be > > creatorsName: cn=3DManager,cn=3Dlog,dc=3Dmycorp.it > > createTimestamp: 20100913093021Z > > entryCSN: 20100913093021.411398Z#000000#003#000000 > > modifiersName: cn=3DManager,cn=3Dlog,dc=3Dmycorp.it > > modifyTimestamp: 20100913093021Z > > --- END > > > > Is this a software bug? > > > > If yes, do I need to produce other infos related to my environment? > > Hi, I have fixed a couple of bugs in reqControls validation. However a > problem remains: the validator expects control values to consist in > hexadecimal digits (0-9, a-f), while your values in some cases aren't. > This could be related to interoperation issues between different slapd > versions, although I couldn't go back to the point where this change in > syntax occurred, if any. > > p. > > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --00504502c82c9d7fc8049b363033 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, the (same?) problem arises again. I downloaded the upgraded s= ource, created a new accesslog and today tried to slapcat/drop/slapadd. = This is the error that I'm encountering: [ldap@ldap03 db_log]$ t= ime /usr/local/openldap/sbin/slapadd -b "cn=3Dlog03,dc=3D<a href=3D"ht= tp://mycorp.it">mycorp.it</a>" -l dump_ldap_dblog_20110201.ldif .###=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 17.14% eta 01h17= m elapsed=A0=A0=A0=A0=A0=A0=A0=A0=A0 15m56s spd 443.0 k/s str2entry: invali= d value for attributeType reqAttr #1 (syntax 1.3.6.1.4.1.1466.115.121.1.15)= slapadd: could not parse entry (line=3D13502606) _###=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 17.14% eta 01h17= m elapsed=A0=A0=A0=A0=A0=A0=A0=A0=A0 15m56s spd 330.0 k/s Closing DB...<= br> The corrupted entry is: dn: reqStart=3D20110128141509.000004Z= ,cn=3Dlog03,dc=3D<a href=3D"http://mycorp.it">mycorp.it</a> objectClass: auditSearch structuralObjectClass: auditSearch reqStart:= 20110128141509.000004Z reqEnd: 20110128141510.000000Z reqType: searc= h reqSession: 6521 reqAuthzID: cn=3DManager,dc=3Dmyregion,dc=3D<a hre= f=3D"http://mycorp.it">mycorp.it</a> reqDN: uid=3Dpe1748,ou=3DPeople,dc=3Dmyregion,dc=3D<a href=3D"http://mycorp= .it">mycorp.it</a> reqResult: 0 reqScope: base reqDerefAliases: ne= ver reqAttrsOnly: FALSE reqFilter: (&(objectClass=3D*)) reqAtt= r: * reqAttr: reqEntries: 1 reqTimeLimit: -1 reqSizeLimit: 500 entry= UUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf creatorsName: cn=3DManager,cn= =3Dlog03,dc=3D<a href=3D"http://mycorp.it">mycorp.it</a> createTimestamp= : 20110128141510Z entryCSN: 20110128141510.000116Z#000000#003#000000 modifiersName: cn=3DM= anager,cn=3Dlog03,dc=3D<a href=3D"http://mycorp.it">mycorp.it</a> modify= Timestamp: 20110128141510Z Thanks =A0=A0=A0=A0=A0=A0 Marco Pi= zzoli <div class=3D"gmail_quote">On Sun, Jan 2, 2011 at 4:01 PM, <<a href=3D"mailto:masarati@aero.polimi.it">masarati(a)aero.pol= imi.it</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"= margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddi= ng-left: 1ex;"> > Full_Name: Marco Pizzoli > Version: 2.4.23 > OS: Linux x86_64 > URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ft= p://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (193.41.84.11) > > > Hi, > I had a problem with my Accesslog database. > I was investigating an anomaly that I had and, in doing this, I tried = to: > - backup (slapcat) my accesslog db > - drop the entire db (rm -f alock, *.bdb, log.*, __db*) > - slapadd the db > > In slapadd I obtained this error: > > --- BEGIN > /usr/sbin/slapadd -b "cn=3Dlog,dc=3D<a href=3D"http://mycorp.it" = target=3D"_blank">mycorp.it</a>" -l > /srv/bck/dump_db_log.ldif.20100916 > . =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0.00% eta 08h35m elapsed= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spd =A090.2 > k/s > str2entry: invalid value for attributeType reqControls #0 (syntax > 1.3.6.1.4.1.4203.666.11.5.3.1) > slapadd2.4: could not parse entry (line=3D4907) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0.01% eta 05h58m elapsed= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spd 205.7 > k/s > Closing DB... > --- END > > I went to that line and found this entry: > > --- BEGIN > dn: reqStart=3D20100913065628.000008Z,cn=3Dlog,dc=3D<a href=3D"http://= mycorp.it" target=3D"_blank">mycorp.it</a> > objectClass: auditSearch > structuralObjectClass: auditSearch > reqStart: 20100913065628.000008Z > reqEnd: 20100913065628.000009Z > reqType: search > reqSession: 1129 > reqAuthzID: > cn=3Dsyncrepl-ldap04,ou=3Dutenze_tecniche_openldap,ou=3DGestori,dc=3D<= a href=3D"http://mycorp.it" target=3D"_blank">mycorp.it</a> > reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue > "30440K0103043M7269643N > =A03030332M7369643N3030342M63736O3N32303130303931333036353130362O39323= 43735355K2 > =A0330303030303023303033233030303030300001PP"} > reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE} > reqDN: dc=3D<a href=3D"http://mycorp.it" target=3D"_blank">mycorp.it</= a> > reqResult: 0 > reqScope: base > reqDerefAliases: never > reqAttrsOnly: TRUE > reqFilter: (objectclass=3D*) > reqAttr: 1.1 > reqEntries: 0 > reqTimeLimit: -1 > reqSizeLimit: 1 > entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7 > creatorsName: cn=3DManager,cn=3Dlog,dc=3D<a href=3D"http://mycorp.it" = target=3D"_blank">mycorp.it</a> > createTimestamp: 20100913065628Z > entryCSN: 20100913065628.167225Z#000000#003#000000 > modifiersName: cn=3DManager,cn=3Dlog,dc=3D<a href=3D"http://mycorp.it"= target=3D"_blank">mycorp.it</a> > modifyTimestamp: 20100913065628Z > --- END > > Having produced this ldif using slapcat and not having "touched&q= uot; the > environment > in between could I assume this to be a bug? > The entry showed is related to an access made by another OL server of = my > deployment, which is in mirrormode(=3Dtrue). > This OL is 2.4.23 with BDB4.8.30. Other OLs are 2.4.22 with BDB4.8.26<= br> > > > I deleted this entry and retried the import. > Now I have the following error: > --- BEGIN > /usr/sbin/slapadd2.4 -b "cn=3Dlog,dc=3D<a href=3D"http://mycorp.i= t" target=3D"_blank">mycorp.it</a>" -l > /tmp/dump_db_log.ldif.20100916_Corrected > " =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4.69% eta 01h07m el= apsed =A0 =A0 =A0 =A0 =A003m19s spd 542.3 > k/s > str2entry: invalid value for attributeType reqRespControls #0 (syntax<= br> > 1.3.6.1.4.1.4203.666.11.5.3.1) > slapadd2.4: could not parse entry (line=3D3099715) > * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4.70% eta 01h07m elapsed= =A0 =A0 =A0 =A0 =A003m20s spd 979.8 > k/s > Closing DB... > --- END > > The "corrupted" entry is this one: > > --- BEGIN > dn: reqStart=3D20100913093021.000000Z,cn=3Dlog,dc=3D<a href=3D"http://= mycorp.it" target=3D"_blank">mycorp.it</a> > objectClass: auditBind > structuralObjectClass: auditBind > reqStart: 20100913093021.000000Z > reqEnd: 20100913093021.000001Z > reqType: bind > reqSession: 2746 > reqAuthzID: > reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1} > reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000= "} > reqDN: uid=3Dpe1597,ou=3DPeople,dc=3D<a href=3D"http://mycorp.it" targ= et=3D"_blank">mycorp.it</a> > reqResult: 0 > reqVersion: 3 > reqMethod: SIMPLE > entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be > creatorsName: cn=3DManager,cn=3Dlog,dc=3D<a href=3D"http://mycorp.it" = target=3D"_blank">mycorp.it</a> > createTimestamp: 20100913093021Z > entryCSN: 20100913093021.411398Z#000000#003#000000 > modifiersName: cn=3DManager,cn=3Dlog,dc=3D<a href=3D"http://mycorp.it"= target=3D"_blank">mycorp.it</a> > modifyTimestamp: 20100913093021Z > --- END > > Is this a software bug? > > If yes, do I need to produce other infos related to my environment?<br= > Hi, I have fixed a couple of bugs in reqControls validation. =A0However a<b= r> problem remains: the validator expects control values to consist in hexadecimal digits (0-9, a-f), while your values in some cases aren't.<= br> This could be related to interoperation issues between different slapd versions, although I couldn't go back to the point where this change in= syntax occurred, if any. p. </blockquote></div> -- _______________________= __________________ Non =E8 forte chi non cade, ma chi cadendo ha la forz= a di rialzarsi. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morrison <div style=3D"visibility: hidden; left: -5000px; position: absolute; z-inde= x: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden;= word-wrap: break-word; color: black; font-size: 10px; text-align: left; li= ne-height: 130%;" id=3D"avg_ls_inline_popup"> </div> --00504502c82c9d7fc8049b363033--

1 0

Réf. : Re: (ITS#6810) slapd crashes writing to bdb backend
by Bruno_Haleblian＠carrefour.com 01 Feb '11

01 Feb '11

--0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE Content-type: multipart/alternative; Boundary="1__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE" --1__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE Content-type: text/plain; charset=US-ASCII Hi, Quanah, Here are my answers plus some comments. All is under ext3 fs BDB log files and data files are one seperate filesystem BDB is 4.6.21 with patch 4 (as provided by http://ltb-project.org/wiki/download ) Running on a VSPhere4 VM - this hardware emulated : 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01) 00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 08) 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08) 00:07.7 System peripheral: VMware Virtual Machine Communication Interface (rev 10) 00:0f.0 VGA compatible controller: VMware SVGA II Adapter 00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01) The 2 servers are in mirror mode. See below the diff between their conf and here's a slapd.conf extract plus the DB_CONFIG file. Most parameters have been provided in the early ages with the old slapd (2.2.x). Mirroring setup is based on admin guide -------------- slapd.conf excerpt -------------- # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include my schemas serverID 2 pidfile /var/ldap/server/var/run/slapd.pid argsfile /var/ldap/server/var/run/slapd.args loglevel 256 allow bind_v2 gentlehup off idletimeout 3600 defaultsearchbase "dc=carrefour,dc=com" timelimit unlimited sizelimit unlimited database bdb suffix "dc=carrefour,dc=com" rootdn "cn=*******,dc=carrefour,dc=com" rootpw ******* directory /var/ldap/data cachesize 500000 maxderefdepth 5 checkpoint 512 720 # Indices to maintain index objectclass,entryCSN,entryUUID eq index uid pres,eq,sub index cn,sn pres,eq,sub,subany index memberOf,eduPersonOrgUnitDN,eduPersonPrimaryOrgUnitDN,employeeNumber,seeAlso eq index businessCategory eq index eduPersonAffiliation,employeeType eq index mail eq index givenName eq index userCertificate eq # some acces rules, granting write user replic dn="uid=replic,dc=carrefour,dc=com" #... overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=001 provider=ldap://X.X.X.X bindmethod=simple binddn="uid=replic,dc=carrefour,dc=com" credentials=********** searchbase="dc=carrefour,dc=com" schemachecking=on type=refreshAndPersist retry="20 +" mirrormode on # pour cacti database monitor ------------- -------------- slapd.conf diff between mirror peers -------------- < serverID 1 --- > serverID 2 27c27 < loglevel 0 --- > loglevel 256 132c132 < provider=ldap://X.X.X.X --- > provider=ldap://X.X.X.Y -------------- DB_CONFIG -------------- #==================================================================== # BDB configuration # # Provided by LTB-project (http://www.ltb-project.org) #==================================================================== set_cachesize 1 0 1 set_flags DB_LOG_AUTOREMOVE set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 set_lg_dir /var/ldap/logs -------------- Regards Bruno HALEBLIAN |---------+----------------------------> | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |---------+----------------------------> >---------------------------------------------------------------------------------------------------------------------| | | | Quanah Gibson-Mount <quanah(a)zimbra.com> | | | |Pour : bruno_haleblian(a)carrefour.com, openldap-its(a)openldap.org | |cc : | |Objet : Re: (ITS#6810) slapd crashes writing to bdb backend | | | | 31/01/2011 22:14 | >---------------------------------------------------------------------------------------------------------------------| --On Friday, January 28, 2011 9:47 AM +0000 bruno_haleblian(a)carrefour.com wrote: > Full_Name: Bruno HALEBLIAN > Version: 2.4.23 > OS: RHEL 5.5/64 bits > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.243.12.111) > > > Hello, > I'm stuck with "random" slapd crashes, my slapd has been tested > successfully in read mode but since I run updates, I get several crashes > a day, with no BDB corruption (recover and restart OK) but I can't let > this go to production stage. > > Here's the first core stack I caught, I'll send more if I meet different > ones. > > Thanks for your help. Hi Bruno, What type of filesystem is BDB located on? I.e., NFS, ext3, SAN, etc. Also, what version of BDB are you using from Oracle? Can you provide your configuration file/cn=config directory (minus any passwords)? Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration This e-mail and any attachment are confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Unauthorized publication, use, dissemination, forwarding, printing or copying of this e-mail and its associated attachments is strictly prohibited. http://disclaimer.carrefour.com/ Let's respect the environment together. Only print this message if necessary --1__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE Content-type: text/html; charset=US-ASCII Content-Disposition: inline <html><body> <tt>Hi,</tt> <tt>Quanah,</tt> <tt>Here are my answers plus some comments.</tt> <tt>All is under ext3 fs</tt> <tt>BDB log files and data files are one seperate filesystem</tt> <tt>BDB is 4.6.21 with patch 4 (as provided by <a href="http://ltb-project.org/wiki/download">http://ltb-project.org/wiki/download</a> )</tt> <tt>Running on a VSPhere4  VM - this hardware emulated : </tt> <tt>00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01)</tt> <tt>00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01)</tt> <tt>00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 08)</tt> <tt>00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)</tt> <tt>00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)</tt> <tt>00:07.7 System peripheral: VMware Virtual Machine Communication Interface (rev 10)</tt> <tt>00:0f.0 VGA compatible controller: VMware SVGA II Adapter</tt> <tt>00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01)</tt> <tt>The 2 servers are in mirror mode. See below the diff between their conf</tt> <tt>and here's a slapd.conf extract plus the DB_CONFIG file. </tt> <tt>Most parameters have been provided in the early ages with the old slapd (2.2.x).</tt> <tt>Mirroring setup is based on admin guide</tt> <tt>--------------</tt> <tt>slapd.conf excerpt</tt> <tt>--------------</tt> <tt># See slapd.conf(5) for details on configuration options.</tt> <tt># This file should NOT be world readable.</tt> <tt>#</tt> <tt>include         my schemas</tt> <tt>serverID        2</tt> <tt>pidfile         /var/ldap/server/var/run/slapd.pid</tt> <tt>argsfile        /var/ldap/server/var/run/slapd.args</tt> <tt>loglevel        256</tt> <tt>allow   bind_v2</tt> <tt>gentlehup       off</tt> <tt>idletimeout     3600</tt> <tt>defaultsearchbase       "dc=carrefour,dc=com"</tt> <tt>timelimit       unlimited</tt> <tt>sizelimit       unlimited</tt> <tt>database        bdb</tt> <tt>suffix          "dc=carrefour,dc=com"</tt> <tt>rootdn          "cn=*******,dc=carrefour,dc=com"</tt> <tt>rootpw          *******</tt> <tt>directory       /var/ldap/data</tt> <tt>cachesize       500000</tt> <tt>maxderefdepth   5</tt> <tt>checkpoint      512     720</tt> <tt># Indices to maintain</tt> <tt>index           objectclass,entryCSN,entryUUID eq</tt> <tt>index           uid     pres,eq,sub</tt> <tt>index           cn,sn   pres,eq,sub,subany</tt> <tt>index           memberOf,eduPersonOrgUnitDN,eduPersonPrimaryOrgUnitDN,employeeNumber,seeAlso    eq</tt> <tt>index           businessCategory eq</tt> <tt>index           eduPersonAffiliation,employeeType eq</tt> <tt>index           mail    eq</tt> <tt>index           givenName       eq</tt> <tt>index           userCertificate eq</tt> <tt># some acces rules, granting write user replic dn="uid=replic,dc=carrefour,dc=com"</tt> <tt>#...</tt> <tt>overlay syncprov</tt> <tt>syncprov-checkpoint 100 10</tt> <tt>syncprov-sessionlog 100</tt> <tt>syncrepl rid=001</tt> <tt>                provider=ldap://X.X.X.X</tt> <tt>                bindmethod=simple</tt> <tt>                binddn="uid=replic,dc=carrefour,dc=com"</tt> <tt>                credentials=**********</tt> <tt>                searchbase="dc=carrefour,dc=com"</tt> <tt>                schemachecking=on</tt> <tt>                type=refreshAndPersist</tt> <tt>                retry="20 +"</tt> <tt>mirrormode on</tt> <tt># pour cacti</tt> <tt>database monitor</tt> <tt>-------------</tt> <tt>--------------</tt> <tt>slapd.conf diff between mirror peers</tt> <tt>--------------</tt> <tt>< serverID        1</tt> <tt>---</tt> <tt>> serverID        2</tt> <tt>27c27</tt> <tt>< loglevel        0</tt> <tt>---</tt> <tt>> loglevel        256</tt> <tt>132c132</tt> <tt><                 provider=ldap://X.X.X.X</tt> <tt>---</tt> <tt>>                 provider=ldap://X.X.X.Y</tt> <tt>--------------</tt> <tt>DB_CONFIG</tt> <tt>--------------</tt> <tt>#====================================================================</tt> <tt># BDB configuration</tt> <tt>#</tt> <tt># Provided by LTB-project (<a href="http://www.ltb-project.org">http://www.ltb-project.org</a>)</tt> <tt>#====================================================================</tt> <tt>set_cachesize   1 0 1</tt> <tt>set_flags               DB_LOG_AUTOREMOVE</tt> <tt>set_lg_regionmax        1048576</tt> <tt>set_lg_max              10485760</tt> <tt>set_lg_bsize            2097152</tt> <tt>set_lg_dir      /var/ldap/logs</tt> <tt>--------------</tt> <tt> </tt> Regards Bruno HALEBLIAN <img width="16" height="16" src="cid:1__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com" border="0" alt="Inactive hide details for unnamed section"> <table V5DOTBL=true width="100%" border="0" cellspacing="0" cellpadding="0"> <tr valign="top"><td width="1%"><img width="72" height="1" src="cid:2__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com" border="0" alt=""> </td><td style="background-image:url(cid:3__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com); background-repeat: no-repeat; " width="1%"><img width="222" height="1" src="cid:2__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com" border="0" alt=""> </td><td width="100%"><img width="1" height="1" src="cid:2__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com" border="0" alt=""> Quanah Gibson-Mount <quanah(a)zimbra.com> Pour : bruno_haleblian(a)carrefour.com, openldap-its(a)openldap.org cc : Objet : Re: (ITS#6810) slapd crashes writing to bdb backend 31/01/2011 22:14</td></tr> </table> <tt>--On Friday, January 28, 2011 9:47 AM +0000 bruno_haleblian(a)carrefour.com wrote: > Full_Name: Bruno HALEBLIAN > Version: 2.4.23 > OS: RHEL 5.5/64 bits > URL: </tt><tt><a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a></tt><tt> > Submission from: (NULL) (92.243.12.111) > > > Hello, > I'm stuck with "random" slapd crashes, my slapd has been tested > successfully in read mode but since I run updates, I get several crashes > a day, with no BDB corruption (recover and restart OK) but I can't let > this go to production stage. > > Here's the first core stack I caught, I'll send more if I meet different > ones. > > Thanks for your help. Hi Bruno, What type of filesystem is BDB located on?  I.e., NFS, ext3, SAN, etc. Also, what version of BDB are you using from Oracle?  Can you provide your configuration file/cn=config directory (minus any passwords)? Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra ::  the leader in open source messaging and collaboration </tt> <div class=Section1> This e-mail and any attachment are confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Unauthorized publication, use, dissemination, forwarding, printing or copying of this e-mail and its associated attachments is strictly prohibited. <a href="http://disclaimer.carrefour.com"> http://disclaimer.carrefour.com </a> Let's respect the environment together. Only print this message if necessary <o:p></o:p> </div> </body></html> --1__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE-- --0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBF2B9DFA5BFCE8f9e8a93df(a)carrefour.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIX lI+py+0PopwxUbpuZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFk IFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=4EBBF2B9DFA5BFCE8f9e8a93df(a)carrefour.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE Content-type: image/gif; name="pic10697.gif" Content-Disposition: inline; filename="pic10697.gif" Content-ID: <3__=4EBBF2B9DFA5BFCE8f9e8a93df(a)carrefour.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIue zf///wAAAAAAAAAAAAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq7046827 70RiFMRinqggEUNSHIchG0BCfHhOjAuhEDeUqTASLCbBhQrhG7xis2j0lssN DopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYRRghXcAGFhoUE TwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09l mgkHLZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtC KW3jfz4uMKmq3xu4N0nKBVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQ EEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAITihRL/4FEwbp28BXMMcoscQC VxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFRM00oQAqN IstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE 4zk+T6FGuQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3m pOaKnL0Z2EKvNMSILEThKhCgzMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI +LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpbqxIKsjUPRgD7I2XYV6wy rOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33YEWQ YNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1 KOODHiu+4aEwNEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcs oCWOOUwgltIwAKRxJgbIkJAQZEq02YliZnpZZ4BH3CnYOXldOUOfQoYDqF1L FHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCcoCgrMFsROrIEX3o2w hVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eI xJJoUBc+3CbBuwZEV5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4se nwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvHESfCwVt5hTgYiqQqtdRNHQIU1PJ3 3ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKTmrKIN07AnGcI 9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9 aQcw9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgL L/r1R40BZEnuBWgmQEybjqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpb jVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPlfmh+xl4WtR0zGu24I4KbMQm3 lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIAOw== --0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE--

1 0

Re: (ITS#6404) tests return success on failure
by h.b.furuseth＠usit.uio.no 01 Feb '11

01 Feb '11

Reopening this ITS. tests/scripts/test038-retcode rev 1.9 can be imported to RE24, it's a mislabeled fix for this. I would commit the following fix for test020-proxycache, except I'd like to know why the test deliberately does 'exit 0' on some failures. 'exit 0' #1-4 are OK, but I do not understand the next 5 of them from: rev 1.34 (hyc) ITS#6152 add tests for cache refresh and Bind caching rev 1.35 (hyc) ITS#6152 test pwdModify If nothing else, these success exits should first give a message which clarifies that the condition which caused the exit is not a bug. As in hunk #1 below. Index: test020-proxycache --- test020-proxycache 4 Jan 2011 23:43:43 -0000 1.40 +++ test020-proxycache 1 Feb 2011 09:39:19 -0000 @@ -153,5 +153,5 @@ RC=$? if test $RC != 0 ; then - echo "Debug messages unavailable, test aborted..." + echo "Debug messages unavailable, remaining test skipped" test $KILLSERVERS != no && kill -HUP $KILLPIDS && wait exit 0 @@ -257,5 +257,5 @@ echo "ldapsearch should have failed!" test $KILLSERVERS != no && kill -HUP $KILLPIDS - exit $RC + exit 1 ;; 4) @@ -284,5 +284,5 @@ echo "ldapsearch should have failed!" test $KILLSERVERS != no && kill -HUP $KILLPIDS - exit $RC + exit 1 ;; 4) @@ -407,5 +407,5 @@ echo "ldapsearch should have failed!" test $KILLSERVERS != no && kill -HUP $KILLPIDS - exit $RC + exit 1 ;; 4) @@ -434,5 +434,5 @@ echo "ldapsearch should have failed!" test $KILLSERVERS != no && kill -HUP $KILLPIDS - exit $RC + exit 1 ;; 4) -- Hallvard

1 0

Re: (ITS#6755) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by hyc＠symas.com 01 Feb '11

01 Feb '11

hyc(a)symas.com wrote: > Howard Chu wrote: >> jgilmour(a)techsmog.com wrote: >>> Full_Name: Josh Gilmour >>> Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14) >>> OS: CentOS release 5.4 32bit >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (38.112.23.58) >>> >>> >>> I get a segfault when using the following command and applying a filter file. If >>> we remove the -f, the command runs properly. It doesn't seem to be a major >>> security issue (or one at all, I'm not sure), but it does seem to be a bug I >>> believe... >> >> OpenLDAP 2.3 is no longer supported. If you can reproduce this bug in a >> current release please followup with the relevant stack trace, otherwise this >> ITS will be closed. Currently I see no such symptom in 2.4.x. >> > Valgrind disagreed with me, the bug was still present in 2.4. Fixed in HEAD. > But the fix needs some more thought. I don't believe this combination of options actually makes any sense; we should probably just disallow it. -- -- 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#6818) back-meta: do not denormalize attrs without equality rule
by h.b.furuseth＠usit.uio.no 01 Feb '11

01 Feb '11

masarati(a)aero.polimi.it writes: > Subject: (ITS#6818) back-meta: do not denormalize attrs without equality rule Is this denormalizion a user-visible or internal matter? -- Hallvard

1 0

Re: (ITS#6755) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by hyc＠symas.com 31 Jan '11

31 Jan '11

Howard Chu wrote: > jgilmour(a)techsmog.com wrote: >> Full_Name: Josh Gilmour >> Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14) >> OS: CentOS release 5.4 32bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (38.112.23.58) >> >> >> I get a segfault when using the following command and applying a filter file. If >> we remove the -f, the command runs properly. It doesn't seem to be a major >> security issue (or one at all, I'm not sure), but it does seem to be a bug I >> believe... > > OpenLDAP 2.3 is no longer supported. If you can reproduce this bug in a > current release please followup with the relevant stack trace, otherwise this > ITS will be closed. Currently I see no such symptom in 2.4.x. > Valgrind disagreed with me, the bug was still present in 2.4. Fixed in 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#6810) slapd crashes writing to bdb backend
by quanah＠zimbra.com 31 Jan '11

31 Jan '11

--On Friday, January 28, 2011 9:47 AM +0000 bruno_haleblian(a)carrefour.com wrote: > Full_Name: Bruno HALEBLIAN > Version: 2.4.23 > OS: RHEL 5.5/64 bits > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.243.12.111) > > > Hello, > I'm stuck with "random" slapd crashes, my slapd has been tested > successfully in read mode but since I run updates, I get several crashes > a day, with no BDB corruption (recover and restart OK) but I can't let > this go to production stage. > > Here's the first core stack I caught, I'll send more if I meet different > ones. > > Thanks for your help. Hi Bruno, What type of filesystem is BDB located on? I.e., NFS, ext3, SAN, etc. Also, what version of BDB are you using from Oracle? Can you provide your configuration file/cn=config directory (minus any passwords)? Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6816) Patch - Mozilla NSS - documentation changes
by quanah＠zimbra.com 31 Jan '11

31 Jan '11

--On Monday, January 31, 2011 9:04 PM +0000 hyc(a)symas.com wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.23 (current CVS HEAD) >> OS: RHEL6 >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-add-moznss-to-docs-20110 >> 130.patch Submission from: (NULL) (76.113.111.209) >> >> >> This adds documentation for Mozilla NSS. Man page TLS settings and >> directives, and Admin Guide. I tested the man pages, but I wasn't sure >> how to generate the docs from the .sdf files - hopefully they will work >> ok without extensive changes. > > Thanks, just needed some minor touch up. With this in place I've decided > we're ready to advertise support for Mozilla NSS now, so I've rolled in > the configure.in patch (from ITS#5698) into RE24. technically, ITS#5696, if anyone is tracking this bug. :P --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6816) Patch - Mozilla NSS - documentation changes
by hyc＠symas.com 31 Jan '11

31 Jan '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 (current CVS HEAD) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-add-moznss-to-docs-20110130… > Submission from: (NULL) (76.113.111.209) > > > This adds documentation for Mozilla NSS. Man page TLS settings and directives, > and Admin Guide. I tested the man pages, but I wasn't sure how to generate the > docs from the .sdf files - hopefully they will work ok without extensive > changes. Thanks, just needed some minor touch up. With this in place I've decided we're ready to advertise support for Mozilla NSS now, so I've rolled in the configure.in patch (from ITS#5698) into RE24. > These patch files are 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#6818) back-meta: do not denormalize attrs without equality rule
by masarati＠aero.polimi.it 31 Jan '11

31 Jan '11

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

1 0

(ITS#6817) idassert-bind with SASL issues
by masarati＠aero.polimi.it 31 Jan '11

31 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.14.92) Submitted by: ando When idassert-bind is configured to use SASL bind, an "authcID" needs to be provided, while the "binddn" is not needed. However, if a "binddn" is not provided as well, in some cases the proxiedAuthz control may be used incorrectly. The need to configure the "binddn" is not documented, so this ITS is minimally addressed by documenting this requirement. If the "binddn" is provided, everything works as expected, with the only minor issue that the DN of the user as it is known to back-meta may not match the actual identity the "authcID" assumed on the remote server. The "right" way to address this problem consists in performing a "WhoAmI" (RFC 4532) right after the bind, or better use a "authorization identity control" (RFC 3829) along with the bind operation. Both approaches should be implemented, but they should not be used unless explicitly requested. p.

1 0

(ITS#6816) Patch - Mozilla NSS - documentation changes
by rmeggins＠redhat.com 31 Jan '11

31 Jan '11

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-add-moznss-to-docs-20110130… Submission from: (NULL) (76.113.111.209) This adds documentation for Mozilla NSS. Man page TLS settings and directives, and Admin Guide. I tested the man pages, but I wasn't sure how to generate the docs from the .sdf files - hopefully they will work ok without extensive changes. These patch files are 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#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 31 Jan '11

31 Jan '11

This is a multi-part message in MIME format. --------------090509020601080703090604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/28/2011 08:27 PM, Howard Chu wrote: >> I'm running into multiple problems here. The core problem seems to be >> that enabling ppolicy_forward_updates breaks the chaining overlay such that >> it binds anonymously instead of with SASL EXTERNAL. > > That's because your authz-regexp is wrong. You mapped "cn=localhost" but > when using SASL EXTERNAL, the user's DN is the complete certificate DN. > In your case, "cn=localhost,o=OpenLDAP,st=Some-State,c=US" > > The reason this didn't break replication is because in this test, > everything has anonymous read access so the consumer was able to pull > what it needed. Hmm, I'm not quite seeing what you're saying here. For example, in slapd.1.log, *before* ppolicy_forward_updates (olcPPolicyForwardUpdates) is enabled, I can see the certificate being mapped exactly as I expect it: ===== ==> rewrite_context_apply [depth=1] res={0,'cn=localhost,dc=example,dc=com'} [rw] authid: "cn=localhost,o=openldap,st=some-state,c=us" -> "cn=localhost,dc=example,dc=com" [...] <==slap_sasl2dn: Converted SASL name to cn=localhost,dc=example,dc=com slap_sasl_getdn: dn:id converted to cn=localhost,dc=example,dc=com SASL Canonicalize [conn=1004]: slapAuthcDN="cn=localhost,dc=example,dc=com" SASL proxy authorize [conn=1004]: authcid="cn=localhost,o=openldap,st=some-state,c=us" authzid="cn=localhost,o=openldap,st=some-state,c=us" conn=1004 op=1 BIND authcid="cn=localhost,o=openldap,st=some-state,c=us" authzid="cn=localhost,o=openldap,st=some-state,c=us" SASL Authorize [conn=1004]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 conn=1004 op=1 BIND dn="cn=localhost,dc=example,dc=com" mech=EXTERNAL sasl_ssf=0 ssf=256 do_bind: SASL/EXTERNAL bind: dn="cn=localhost,dc=example,dc=com" sasl_ssf=0 ===== Based on this, I'm assuming that my authz-regexp is behaving as I'm intending -- looking for a certificate with "cn=localhost" anywhere in the subject DN, and mapping that to the DN cn=localhost,dc=example,dc=com in the directory. It's only *after* olcPPolicyForwardUpdates is enabled that the SASL EXTERNAL authentication stops working. Can you help me understand the disconnect between what I'm seeing and what you're saying? > I didn't get this far because your test certificate is now expired. I > guess I can substitute some other certs and look at it again, but I > think the core issue is your misconfigured authz-regexp. I have updated the expiration date on the certificate and have attached it to this message. > Better to rename your scripts when you modify one of our existing ones. > E.g. test999-xxxxxx and just create new data files instead of modifying > ours. Ok, will keep this in mind. Thanks, -Kartik --------------090509020601080703090604 Content-Type: text/plain; name="localhost.crt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="localhost.crt" -----BEGIN CERTIFICATE----- MIICCTCCAXICCQC1gKCIQ2we4DANBgkqhkiG9w0BAQUFADBJMQswCQYDVQQGEwJV UzETMBEGA1UECBMKU29tZS1TdGF0ZTERMA8GA1UEChMIT3BlbkxEQVAxEjAQBgNV BAMTCWxvY2FsaG9zdDAeFw0xMTAxMzExNjE1NTdaFw0xMjAxMzExNjE1NTdaMEkx CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMREwDwYDVQQKEwhPcGVu TERBUDESMBAGA1UEAxMJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQCqZU3fA/o/y5gHXxm0JpdMoV64LAOIPgcZTHv4+OkVjoW2gMHT8AMerJzk Cr07y1JjfeqV1c7sZl6+aqC3H+HLs0cCtXFKPFY9FmoehO9KBksDaH5o2f7h104r s/xg2cNTDy1dFFJUzMWQIc8TU7+GpjS3gP0/9gNlIyiLdio9LwIDAQABMA0GCSqG SIb3DQEBBQUAA4GBAGFeVSjX4ZjLmrU7oob4CyoWO2ekeVyldWLjVOUCyeSMae3n I1/kQ5AbGrJdtQQeLyRhIQKUM2a1AqjPLW1QKPXHnHnbsnzuWmC2C9fIw1C3o0yZ UBsxlqoA7K486qeyAb6bUO5X2JD2rOng+HL/pgKlo9h8dW23tWj4CEUMepOh -----END CERTIFICATE----- --------------090509020601080703090604--

1 0

Re: (ITS#6806) Invalid ldapadd crashes openldap with ndb backend
by anderson＠vailsys.com 31 Jan '11

31 Jan '11

I thought I had attached the backtrace when I opened this, sorry. Here is the backtrack from 2.4.23. Compile Options: ./configure --enable-ndb --enable-passwd --enable-modules --enable-slp --enable-crypt --enable-overlays --enable-dynamic --enable-syslog --enable-debug --enable-auditlog --disable-cleartext --enable-wrappers --enable-ppolicy mysql-cluster-gpl-7.1.9a binary distribution from oracle. Line 339 in NdbTransaction.cpp didn't refer to a file that I saw. Let me know if anything else is needed. #0 NdbTransaction::execute (this=0x7fa1ae235659, aTypeOfExec=NdbTransaction::Rollback, abortOption=NdbOperation::DefaultAbortOption, forceSend=0) at NdbTransaction.cpp:339 339 NdbTransaction.cpp: No such file or directory. in NdbTransaction.cpp (gdb) bt #0 NdbTransaction::execute (this=0x7fa1ae235659, aTypeOfExec=NdbTransaction::Rollback, abortOption=NdbOperation::DefaultAbortOption, forceSend=0) at NdbTransaction.cpp:339 #1 0x00000000004f8608 in ndb_back_add () #2 0x000000000043ce34 in fe_op_add () #3 0x000000000043d695 in do_add () #4 0x0000000000435dd9 in ?? () #5 0x000000000043662d in ?? () #6 0x00007fa1b0f43538 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #7 0x00007fa1af7729ca in start_thread () from /lib/libpthread.so.0 #8 0x00007fa1ae27a70d in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () > As always, when you get a core dump, post the gdb backtrace of the dump. Use > the most recent release version, and make sure you use a non-optimized debug > build with all debug symbols intact. All of these instructions are written on > the page where you submit new Issues. >

1 0

Re: (ITS#6684) Patch for autogroup overlay
by moenoel＠informatik.uni-bremen.de 31 Jan '11

31 Jan '11

Am 29.01.2011 21:10, schrieb hyc(a)symas.com: > moenoel(a)informatik.uni-bremen.de wrote: >>> 1) it should simply be comparing the AttributeDescription pointers >>> 2) since the "memberof" attribute is actually configurable in the memberof >>> overlay, there's no guarantee that this is the correct attribute to be looking >>> for. It should also be configurable in your patch. >>> >>> You're using strcasecmp, but your inputs are already normalized values. You >>> should just use ber_bvcmp. >>> >> >> Since I am also interested in this, I took some time to make a new >> patch. I took Norberts original patch, applied it to a current checkout >> from HEAD and tried to fix the issues mentioned by Howard. My initial >> tests are looking good. >> >> My C skills are rather mediocre, though, so I hope I didn't slaughter >> the thing :-) >> >> http://www.informatik.uni-bremen.de/~moenoel/ldap/christian-manal-autogroup… > > This patch looks pretty good. There are only one or two minor issues with it, > which I will clean up. (E.g., config actions require no mutexes; slapd is > always single-threaded when processing config changes.) > Great, thanks!

1 0

ITS#6815
by masarati＠aero.polimi.it 30 Jan '11

30 Jan '11

> This request is spotted by some ldap clients that I have that every > 30seconds do a dummy ldap search only to keep alive their connection > to the ldap server. These searches are frequent and I have many of > these clients in my deploy, so my accesslog become full of not > significant entries. For this specific purpose, your clients could perform an operation that is not logged; for example, search the rootDSE. p.

1 0

(ITS#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 30 Jan '11

30 Jan '11

Full_Name: Marco Pizzoli Version: ALL OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.41.84.11) Hi, this is a feature request. I would like to have accesslog writing to his db only ldap operations that match some sort of filter, or, in particular, to not to log searches that matches a specific pattern. This request is spotted by some ldap clients that I have that every 30seconds do a dummy ldap search only to keep alive their connection to the ldap server. These searches are frequent and I have many of these clients in my deploy, so my accesslog become full of not significant entries. Thanks in advance Marco Pizzoli

1 0

Re: (ITS#5733) tainted connection
by richton＠nbcs.rutgers.edu 30 Jan '11

30 Jan '11

On Sat, 29 Jan 2011, Howard Chu wrote: > Are people still running into this? Seems like not. Time to close this > issue? I haven't seen it in a while. Closing seems reasonable.

1 0

Re: (ITS#5733) tainted connection
by hyc＠symas.com 29 Jan '11

29 Jan '11

richton(a)nbcs.rutgers.edu wrote: > I saw this three times in testing of HEAD. One backtrace and -d -1: > > https://www.nbcs.rutgers.edu/~richton/test039-bt-200906200640.txt > https://www.nbcs.rutgers.edu/~richton/test039-slapdlog-200906200640.txt > > > These are under libumem with transaction logging enabled. All malloc/free > for a given block can be retrieved, in theory... Are people still running into this? Seems like not. Time to close this 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

Re: (ITS#6749) Shut up "configure monitor database to enable"
by h.b.furuseth＠usit.uio.no 29 Jan '11

29 Jan '11

masarati(a)aero.polimi.it writes: >> Please don't give the "configure monitor database to enable" message >> by default. >> >> Either just remove it, or better, stop cn=config from adding a default >> olcMonitoring: TRUE attribute to olcDatabase objects. (The flag value >> can still default to True if the attribute is absent.) Then you can >> give the message if the _admin_ has explicitly asked for monitoring, >> instead of if slapd has asked for it. > > I disagree; it is not cn=config that defaults database monitoring to TRUE; > actually, it's back-bdb/back-hdb that sets its own monitoring to TRUE as > soon as back-monitor support is compiled and the specific backend > monitoring is successfully initilized. If the admin put 'olcMonitoring: TRUE' in slapd.d but did not include database monitor, that would be poor user config. I'm fine with having bdb set the internal default flag value to TRUE. My protest in that context is against slapd - be it back-bdb or back-config which is to blame - writing the default value to the cn=config LDIF even though the admin never mentioned monitoring. This means that neither the TRUE value of the internal flag nor the presence of the attribute is an indication that the admin asked for monitoring (i.e. set the flag) but forgot to add database monitor. > Maybe this warning can be demoted to LDAP_DEBUG_CONFIG instead of > LDAP_DEBUG_ANY. Yes. Maybe slapd should nag the admin more about bad config, but if so there are plenty of other things which are more important than this and should get a chance to nag the admin before this particular flag gets to do it. IIRC the only other thing which gets to do that now is BDB without DB_CONFIG - which makes sense since that's an entire non-OpenLDAP subsystem which has not been configured. But also: > I understand that one could presume that the lack of database monitor > in the configuration indicates that monitoring is not desired; this > warning, however, tries to address a typical configuration error, when > admins just forget to configure it. No, this is a broken slapd default. It should not be an admin error to not mention a feature he does not want and does not need to know about. And if slapd does nag anyone about it, it should nag admins who do mention either database monitor or the flag, not admins who do not. So slapd should be quiet if it set the flag internally and the admin does not include database monitor. Thus my suggestion to set the flag internally by default but only nag the admin if it was set in cn=config. Unless olcMonitoring:TRUE is a drain on performance or something so it really ought to be off when the data is not used anyway. An alternative (and a change in behavior from now) if you really want this warning, would be to always default monitoring to off. That'll surprise existing users, so the cn=monitor objects could contain some text 'monitoring off for this database, set olcMonitoring to enable'. Personally I don't think a warning is worth such a change in behavior, but then I don't like the warning anyway:-) -- Hallvard

1 0

Re: (ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by hyc＠symas.com 29 Jan '11

29 Jan '11

richm(a)stanfordalumni.org wrote: > The NSS_STRICT_NOFORK environment variable is documented here: > https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables > > Note that if a user really wants the strict pkcs11 behavior, the user > can set the variable to "1" or some other non-empty value (other than > "DISABLED"). > > If you think further documentation is required, I would be happy to > update the Admin Guide, FAQ-o-matic, man pages, etc. That looks fine. Most of our docs were written specifically to OpenSSL but we've added one or two references to GnuTLS since then. I would start by adding to the FAQ-o-Matic: http://www.openldap.org/faq/data/cache/196.html I guess we could update this to mention the availability of GnuTLS and MozNSS support and perhaps a discussion of their pros and cons. (Though in all honesty I cannot think of any pros for using GnuTLS. I would use PolarSSL instead but that's not what the Debian folks asked for...) Hm, this entire FAQ page is far out of date. If you want to add some MozNSS info here go ahead, I'll take a pass at the rest of the page later. -- -- 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#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by richm＠stanfordalumni.org 29 Jan '11

29 Jan '11

The NSS_STRICT_NOFORK environment variable is documented here: https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables Note that if a user really wants the strict pkcs11 behavior, the user can set the variable to "1" or some other non-empty value (other than "DISABLED"). If you think further documentation is required, I would be happy to update the Admin Guide, FAQ-o-matic, man pages, etc.

1 0

Re: (ITS#6684) Patch for autogroup overlay
by hyc＠symas.com 29 Jan '11

29 Jan '11

moenoel(a)informatik.uni-bremen.de wrote: >> 1) it should simply be comparing the AttributeDescription pointers >> 2) since the "memberof" attribute is actually configurable in the memberof >> overlay, there's no guarantee that this is the correct attribute to be looking >> for. It should also be configurable in your patch. >> >> You're using strcasecmp, but your inputs are already normalized values. You >> should just use ber_bvcmp. >> > > Since I am also interested in this, I took some time to make a new > patch. I took Norberts original patch, applied it to a current checkout > from HEAD and tried to fix the issues mentioned by Howard. My initial > tests are looking good. > > My C skills are rather mediocre, though, so I hope I didn't slaughter > the thing :-) > > http://www.informatik.uni-bremen.de/~moenoel/ldap/christian-manal-autogroup… This patch looks pretty good. There are only one or two minor issues with it, which I will clean up. (E.g., config actions require no mutexes; slapd is always single-threaded when processing config changes.) -- -- 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#6806) Invalid ldapadd crashes openldap with ndb backend
by hyc＠symas.com 29 Jan '11

29 Jan '11

anderson(a)vailsys.com wrote: > Full_Name: Nathanael Anderson > Version: 2.4.19 > OS: RHEL 6 (Linux) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.63.156.11) > > > #00_die.ldif > > dn: cn=die,ou=groups,dc=domain,dc=com > objectclass: groupofnames > cn: Operations > description: People in Operations > > ldapadd -x -D "cn=admin,dc=domain,dc=com" -W -f 00_die.ldif > > This will crash the openldap server every time with a Bus error message > > conn=0 op=1 ADD dn="cn=die,ou=groups,dc=domain,dc=com" > Entry (cn=die,ou=groups,dc=domain,dc=com): object class 'groupOfNames' requires > attribute 'member' > conn=0 op=1 RESULT tag=105 err=65 text=object class 'groupOfNames' requires > attribute 'member' > Bus error (core dumped) > As always, when you get a core dump, post the gdb backtrace of the dump. Use the most recent release version, and make sure you use a non-optimized debug build with all debug symbols intact. All of these instructions are written on the page where you submit new Issues. -- -- 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#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by hyc＠symas.com 29 Jan '11

29 Jan '11

richm(a)stanfordalumni.org wrote: > On Sat, Jan 29, 2011 at 3:26 AM,<hyc(a)symas.com> wrote: >> rmeggins(a)redhat.com wrote: >>> Full_Name: Rich Megginson >>> Version: 2.4.23 (current CVS HEAD) >>> OS: RHEL6 >>> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofo= > rk-20110127.patch >>> Submission from: (NULL) (76.113.111.209) >>> >>> >>> There are some applications that acquire a crypto context in the parent = > process >>> and expect that crypto context to work after a fork(). =A0This does not = > work >>> with MozNSS using strict PKCS11 compliance mode. =A0We set the environme= > nt >>> variable NSS_STRICT_NOFORK=3DDISABLED in tlsm_init() to tell the softwar= > e >>> encryption module/token to allow crypto contexts to persist across a for= > k(). >>> However, if you are using some other module or encryption device that su= > pports >>> and expects full PKCS11 semantics, the only recourse is to modify the >>> application to use atfork() handlers to save the crypto context in the p= > arent >>> and restore (and SECMOD_RestartModules) the context in the child. >> >> Sounds like this is a followon to #6802. Is this really critical at this >> point? We really need to close the window on RE24 patches so we can actua= > lly >> cut a release. But if ITS#6802 is actually incomplete, I guess we should = > roll >> this in. > > Yes, it is a followon to 6802 - as it turns out, the patch to 6802 was > incomplete. We have discovered some important applications such as > sshd/su/others that open an LDAP* connection in the parent process, > fork(), and attempt to use the same LDAP* handle in the child. Some > of the other Fedora/Red Hat developers and I had a discussion with one > of the MozNSS developers about this issue, as ldap is not the only > affected area. It was decided that the best thing is to simply > disable the fork() checking in the MozNSS software token pkcs11 crypto > module. This will give us parity with openssl with respect to fork() > behavior. It is a critical issue for Fedora/Red Hat. I understand > that this is coming in late in the game and you may not be able to get > this into RE24. If not, Fedora/Red Hat will carry a patch for this. Is this env var and atfork() workaround already documented in the NSS documentation? Just wondering if we need to say anything about it in our Admin Guide, FAQ-o-Matic, or manpages. -- -- 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#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by richm＠stanfordalumni.org 29 Jan '11

29 Jan '11

On Sat, Jan 29, 2011 at 3:26 AM, <hyc(a)symas.com> wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.23 (current CVS HEAD) >> OS: RHEL6 >> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofo= rk-20110127.patch >> Submission from: (NULL) (76.113.111.209) >> >> >> There are some applications that acquire a crypto context in the parent = process >> and expect that crypto context to work after a fork(). =A0This does not = work >> with MozNSS using strict PKCS11 compliance mode. =A0We set the environme= nt >> variable NSS_STRICT_NOFORK=3DDISABLED in tlsm_init() to tell the softwar= e >> encryption module/token to allow crypto contexts to persist across a for= k(). >> However, if you are using some other module or encryption device that su= pports >> and expects full PKCS11 semantics, the only recourse is to modify the >> application to use atfork() handlers to save the crypto context in the p= arent >> and restore (and SECMOD_RestartModules) the context in the child. > > Sounds like this is a followon to #6802. Is this really critical at this > point? We really need to close the window on RE24 patches so we can actua= lly > cut a release. But if ITS#6802 is actually incomplete, I guess we should = roll > this in. Yes, it is a followon to 6802 - as it turns out, the patch to 6802 was incomplete. We have discovered some important applications such as sshd/su/others that open an LDAP* connection in the parent process, fork(), and attempt to use the same LDAP* handle in the child. Some of the other Fedora/Red Hat developers and I had a discussion with one of the MozNSS developers about this issue, as ldap is not the only affected area. It was decided that the best thing is to simply disable the fork() checking in the MozNSS software token pkcs11 crypto module. This will give us parity with openssl with respect to fork() behavior. It is a critical issue for Fedora/Red Hat. I understand that this is coming in late in the game and you may not be able to get this into RE24. If not, Fedora/Red Hat will carry a patch for this. > >> These patch files are 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. >> > > > -- > =A0 -- Howard Chu > =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 http://www.symas.com > =A0 Director, Highland Sun =A0 =A0 http://highlandsun.com/hyc/ > =A0 Chief Architect, OpenLDAP =A0http://www.openldap.org/project/ > > >

1 0

Re: (ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by hyc＠symas.com 29 Jan '11

29 Jan '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 (current CVS HEAD) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofork-20110… > Submission from: (NULL) (76.113.111.209) > > > There are some applications that acquire a crypto context in the parent process > and expect that crypto context to work after a fork(). This does not work > with MozNSS using strict PKCS11 compliance mode. We set the environment > variable NSS_STRICT_NOFORK=DISABLED in tlsm_init() to tell the software > encryption module/token to allow crypto contexts to persist across a fork(). > However, if you are using some other module or encryption device that supports > and expects full PKCS11 semantics, the only recourse is to modify the > application to use atfork() handlers to save the crypto context in the parent > and restore (and SECMOD_RestartModules) the context in the child. Sounds like this is a followon to #6802. Is this really critical at this point? We really need to close the window on RE24 patches so we can actually cut a release. But if ITS#6802 is actually incomplete, I guess we should roll this in. > These patch files are 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#6814) back-ldap does not handle undefined objectClass values in search filters
by masarati＠aero.polimi.it 29 Jan '11

29 Jan '11

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

1 0

(ITS#6813) Error in ldap_int_connect_cbs call from ldap_connect_to_host
by ipuleston＠sonicwall.com 28 Jan '11

28 Jan '11

Full_Name: Ian Puleston Version: 2.4.23 OS: VxWorks URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.115.118.5) In function ldap_connect_to_host are two calls to ldap_int_connect_cbs. The first for "#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP )" looks OK, but the 2nd for the #else case of that is this: i = ldap_int_connect_cbs( ld, sb, &s, srv, (struct sockaddr *)&sin ); if ( i ) rc = i; else break; But this is inside a for loop that uses i as a counter for the loop control. ldap_int_connect_cbs returns an error code so, unless I'm missing something, setting i to that will break the loop control.

1 0

Re: (ITS#6812) Confused syncprov return codes
by hyc＠symas.com 28 Jan '11

28 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > syncprov_state_ctrl(), syncprov_done_ctrl(), syncprov_sendinfo() and > thus findpres_cb() can return either an LDAP result code, or a negative > number on BER error. I see no code which expects both classes of error > codes. The first functions's callers set rs->sr_err = return value. > At best I guess it'll be ignored or interpreted as LDAP_SERVER_DOWN. I've fixed the return codes. They still get ignored in a few places. -- -- 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#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 28 Jan '11

28 Jan '11

subbarao(a)computer.org wrote: > Full_Name: Kartik Subbarao > Version: 2.4.23 > OS: Debian Linux 5.0.5 > URL: ftp://ftp.openldap.org/incoming/kartik_subbarao.101116.tgz > Submission from: (NULL) (76.99.175.5) > > > I'm trying to get a consumer server to forward ppolicy-related updates to its > provider server, and to use certificate-based authentication (SASL EXTERNAL) > over STARTTLS when authenticating to the provider. > > I'm running into multiple problems here. The core problem seems to be that > enabling ppolicy_forward_updates breaks the chaining overlay such that it binds > anonymously instead of with SASL EXTERNAL. That's because your authz-regexp is wrong. You mapped "cn=localhost" but when using SASL EXTERNAL, the user's DN is the complete certificate DN. In your case, "cn=localhost,o=OpenLDAP,st=Some-State,c=US" The reason this didn't break replication is because in this test, everything has anonymous read access so the consumer was able to pull what it needed. > Another problem is that bind > operations to the consumer server start to return two result messages -- one > with the error code of the chained operation, and one with the error code of the > bind operation. I didn't get this far because your test certificate is now expired. I guess I can substitute some other certs and look at it again, but I think the core issue is your misconfigured authz-regexp. > To simplify reproducing the problem, I've worked with test022-ppolicy in the > openldap test framework. Here, I ran into another issue. I can't seem to be able > to configure sasl external/starttls chaining properly with the cn=config style > configuration that test022-ppolicy applies. The self-signed cert that I'm using > works fine with replication, but it doesn't seem to work with chaining. This may > or may not be another issue that needs to be resolved. > > In any case, with the attached files in the ITS, I hope that what I'm trying to > do and the results that I'm getting should be as clear as possible. Better to rename your scripts when you modify one of our existing ones. E.g. test999-xxxxxx and just create new data files instead of modifying ours. -- -- 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#6806) Invalid ldapadd crashes openldap with ndb backend
by anderson＠vailsys.com 28 Jan '11

28 Jan '11

The same behavior happens with 2.4.23, I initially noticed the problem with 2.4.23, built from source on ubuntu server, and then tried with the rebuilt 2.4.19 rpm on rhel. both die with a bus error message when ldapadd is run on the invalid ldif. Nathanael On Fri, 2011-01-28 at 10:55 -0800, Quanah Gibson-Mount wrote: > --On Thursday, January 27, 2011 3:28 PM +0000 anderson(a)vailsys.com wrote: > > > Full_Name: Nathanael Anderson > > Version: 2.4.19 > > OS: RHEL 6 (Linux) > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (74.63.156.11) > > > Please use a current version of OpenLDAP 2.4 prior to filing a bug report > to ensure the issue has not been fixed in a subsequent release. The > current release is 2.4.23. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6806) Invalid ldapadd crashes openldap with ndb backend
by quanah＠zimbra.com 28 Jan '11

28 Jan '11

--On Thursday, January 27, 2011 3:28 PM +0000 anderson(a)vailsys.com wrote: > Full_Name: Nathanael Anderson > Version: 2.4.19 > OS: RHEL 6 (Linux) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.63.156.11) Please use a current version of OpenLDAP 2.4 prior to filing a bug report to ensure the issue has not been fixed in a subsequent release. The current release is 2.4.23. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6812) Confused syncprov return codes
by h.b.furuseth＠usit.uio.no 28 Jan '11

28 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard syncprov_state_ctrl(), syncprov_done_ctrl(), syncprov_sendinfo() and thus findpres_cb() can return either an LDAP result code, or a negative number on BER error. I see no code which expects both classes of error codes. The first functions's callers set rs->sr_err = return value. At best I guess it'll be ignored or interpreted as LDAP_SERVER_DOWN.

1 0

Re: (ITS#6684) Patch for autogroup overlay
by moenoel＠informatik.uni-bremen.de 28 Jan '11

28 Jan '11

Am 27.01.2011 16:38, schrieb moenoel(a)informatik.uni-bremen.de: >> 1) it should simply be comparing the AttributeDescription pointers >> 2) since the "memberof" attribute is actually configurable in the memberof >> overlay, there's no guarantee that this is the correct attribute to be looking >> for. It should also be configurable in your patch. >> >> You're using strcasecmp, but your inputs are already normalized values. You >> should just use ber_bvcmp. >> > > Since I am also interested in this, I took some time to make a new > patch. I took Norberts original patch, applied it to a current checkout > from HEAD and tried to fix the issues mentioned by Howard. My initial > tests are looking good. > > My C skills are rather mediocre, though, so I hope I didn't slaughter > the thing :-) > > http://www.informatik.uni-bremen.de/~moenoel/ldap/christian-manal-autogroup… > > > Regards, > Christian Manal > > I just noticed that I messed up the copyright notice. I fixed that and replaced the archive, so the link is still valid.

1 0

(ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by rmeggins＠redhat.com 28 Jan '11

28 Jan '11

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofork-20110… Submission from: (NULL) (76.113.111.209) There are some applications that acquire a crypto context in the parent process and expect that crypto context to work after a fork(). This does not work with MozNSS using strict PKCS11 compliance mode. We set the environment variable NSS_STRICT_NOFORK=DISABLED in tlsm_init() to tell the software encryption module/token to allow crypto contexts to persist across a fork(). However, if you are using some other module or encryption device that supports and expects full PKCS11 semantics, the only recourse is to modify the application to use atfork() handlers to save the crypto context in the parent and restore (and SECMOD_RestartModules) the context in the child. These patch files are 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

(ITS#6810) slapd crashes writing to bdb backend
by bruno_haleblian＠carrefour.com 28 Jan '11

28 Jan '11

Full_Name: Bruno HALEBLIAN Version: 2.4.23 OS: RHEL 5.5/64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.243.12.111) Hello, I'm stuck with "random" slapd crashes, my slapd has been tested successfully in read mode but since I run updates, I get several crashes a day, with no BDB corruption (recover and restart OK) but I can't let this go to production stage. Here's the first core stack I caught, I'll send more if I meet different ones. Thanks for your help. kernel: slapd[13284]: segfault at 0000000000000008 rip 000000000052a377 rsp 0000000043fa5160 error 4 Program terminated with signal 11, Segmentation fault. #0 0x000000000052a377 in syncprov_matchops (op=0x182cdb00, opc=0x182d04c8, saveit=1) at syncprov.c:1309 1309 op2.ors_filter = ss->s_op->ors_filter->f_and->f_next; (gdb) where #0 0x000000000052a377 in syncprov_matchops (op=0x182cdb00, opc=0x182d04c8, saveit=1) at syncprov.c:1309 #1 0x000000000052a5e1 in syncprov_op_mod (op=0x182cdb00, rs=<value optimized out>) at syncprov.c:2075 #2 0x000000000049757a in overlay_op_walk (op=0x182cdb00, rs=0x43fa6c70, which=op_modify, oi=0x17b6e2f0, on=0x17b6e4d0) at backover.c:659 #3 0x0000000000497b47 in over_op_func (op=0x182cdb00, rs=0x43fa6c70, which=op_modify) at backover.c:721 #4 0x000000000044c537 in fe_op_modify (op=0x182cdb00, rs=0x43fa6c70) at modify.c:301 #5 0x000000000044cc92 in do_modify (op=0x182cdb00, rs=0x43fa6c70) at modify.c:175 #6 0x0000000000435655 in connection_operation (ctx=0x43fa6dc0, arg_v=<value optimized out>) at connection.c:1109 #7 0x0000000000435c2f in connection_read_thread (ctx=0x43fa6dc0, argv=<value optimized out>) at connection.c:1245 #8 0x000000000054345c in ldap_int_thread_pool_wrapper (xpool=0x17af0350) at tpool.c:685 #9 0x000000339360673d in start_thread () from /lib64/libpthread.so.0 #10 0x0000003392ed3d1d in removexattr () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () (gdb) list *0x000000000052a377 0x52a377 is in syncprov_matchops (syncprov.c:1309). 1304 ldap_pvt_thread_mutex_lock( &ss->s_mutex ); 1305 if (ss->s_flags & PS_FIX_FILTER) { 1306 /* Skip the AND/GE clause that we stuck on in front. We 1307 would lose deletes/mods that happen during the refresh 1308 phase otherwise (ITS#6555) */ 1309 op2.ors_filter = ss->s_op->ors_filter->f_and->f_next; 1310 } 1311 ldap_pvt_thread_mutex_unlock( &ss->s_mutex ); 1312 rc = test_filter( &op2, e, op2.ors_filter ); 1313 }

1 0

(ITS#6809) back-sock compare is missing a newline
by hyc＠OpenLDAP.org 28 Jan '11

28 Jan '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc All of the messages from back-sock to the other socket server are supposed to be terminated by two newlines. The Compare operation only has one.

1 0

Re: (ITS#6807) syncrepl sends incomplete sync cookie in MMR
by hyc＠symas.com 28 Jan '11

28 Jan '11

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD/RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.94.188.8) > Submitted by: hyc > > > In syncrepl_updateCookie() the cookie received from the provider is dup'd as-is. > If the provider is stopped and restarted, this same cookie will be sent back on > the next refresh attempt. In refreshAndPersist mode the cookies sent from the > provider will only contain a single CSN; CSNs from other MMR servers are > omitted. During a restart, because the consumer sends a cookie with only one > CSN, the provider will consider the consumer out of date. > > A fix is coming shortly. For the record... I spent some time considering whether this should actually be fixed in the provider or the consumer. I decided on fixing in the consumer for the sake of network bandwidth/efficiency - in persist mode, a cookie may be sent with every single write operation. Generally only one CSN will be relevant for any given write op, so it would be a waste to send all of the other unchanged CSNs every time. On the consumer side, the consumer must always send all of the context info it has available. This might involve more volume in a request but ordinarily the actual consumer request is only a tiny fraction of the total network traffic. Purists might say that this goes against RFC4533 which states that consumers should treat sync cookies as opaque items, but the OpenLDAP implementation has always relied on exact knowledge of the sync cookie format; this was always required in order to support cascaded replication if nothing else. Also this ITS is specific to MMR, which is not addressed at all in RFC4533. -- -- 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#6808) pcache monitoring cleanup needs monitor entry DN
by masarati＠aero.polimi.it 27 Jan '11

27 Jan '11

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

1 0

Re: (ITS#6791) Patch - Mozilla NSS - cert verify uses incorrect values
by hyc＠symas.com 27 Jan '11

27 Jan '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 (current CVS HEAD) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-cert-verify-uses-incorrect-… > Submission from: (NULL) (76.113.111.209) > > > The cert verify routines were using type SECCertUsage instead of type > SECCertificateUsage. The values are similar, and this was causing verify errors > of SEC_ERROR_INADEQUATE_KEY_USAGE and SEC_ERROR_INADEQUATE_CERT_TYPE. MozNSS > only checks the usage if the cert includes the usage extensions which is why I > didn't see this error earlier. Talk about confusing ... committed to HEAD, thanks. > > These patch files are 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#6807) syncrepl sends incomplete sync cookie in MMR
by hyc＠OpenLDAP.org 27 Jan '11

27 Jan '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc In syncrepl_updateCookie() the cookie received from the provider is dup'd as-is. If the provider is stopped and restarted, this same cookie will be sent back on the next refresh attempt. In refreshAndPersist mode the cookies sent from the provider will only contain a single CSN; CSNs from other MMR servers are omitted. During a restart, because the consumer sends a cookie with only one CSN, the provider will consider the consumer out of date. A fix is coming shortly.

1 0

Re: (ITS#6684) Patch for autogroup overlay
by moenoel＠informatik.uni-bremen.de 27 Jan '11

27 Jan '11

> 1) it should simply be comparing the AttributeDescription pointers > 2) since the "memberof" attribute is actually configurable in the memberof > overlay, there's no guarantee that this is the correct attribute to be looking > for. It should also be configurable in your patch. > > You're using strcasecmp, but your inputs are already normalized values. You > should just use ber_bvcmp. > Since I am also interested in this, I took some time to make a new patch. I took Norberts original patch, applied it to a current checkout from HEAD and tried to fix the issues mentioned by Howard. My initial tests are looking good. My C skills are rather mediocre, though, so I hope I didn't slaughter the thing :-) http://www.informatik.uni-bremen.de/~moenoel/ldap/christian-manal-autogroup… Regards, Christian Manal

1 0

(ITS#6806) Invalid ldapadd crashes openldap with ndb backend
by anderson＠vailsys.com 27 Jan '11

27 Jan '11

Full_Name: Nathanael Anderson Version: 2.4.19 OS: RHEL 6 (Linux) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.63.156.11) #00_die.ldif dn: cn=die,ou=groups,dc=domain,dc=com objectclass: groupofnames cn: Operations description: People in Operations ldapadd -x -D "cn=admin,dc=domain,dc=com" -W -f 00_die.ldif This will crash the openldap server every time with a Bus error message conn=0 op=1 ADD dn="cn=die,ou=groups,dc=domain,dc=com" Entry (cn=die,ou=groups,dc=domain,dc=com): object class 'groupOfNames' requires attribute 'member' conn=0 op=1 RESULT tag=105 err=65 text=object class 'groupOfNames' requires attribute 'member' Bus error (core dumped)

1 0

Re: ITS#6805
by Kurt＠OpenLDAP.org 27 Jan '11

27 Jan '11

On Jan 27, 2011, at 2:30 AM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> The OP expects somehow for the server to prevent the client from =3D >> exposing information when the server has no control over what the = client =3D >> sends. This simply is not possible and hence should not be expected. >>=20 >> Even if the server were configured only with a ldaps:// listener, =3D >> clients would not be precluded from sending a password to the server = in =3D >> the clear. A client could be told to connect to that listener and = send =3D >> a LDAP Simple Bind with password without ever attempting to start = TLS. =3D >> Sure, the server will error, but the password is exposed none the = less. >=20 > While this is true in general there still could be a benefit from = disallowing > connections without StartTLS at the server-side: Yes, and slapd(8) has long supported such a configuration and, in fact, = the OP had such a configuration. > Normally in a serious deployment there are integration tests done with = client > applications for which no real passwords are used. Disallowing = non-protected > connections would reveal misconfiguration immediately and the = application can > then be modified to do the right thing. >=20 > Ciao, Michael.

1 0

Re: ITS#6805
by michael＠stroeder.com 27 Jan '11

27 Jan '11

Kurt(a)OpenLDAP.org wrote: > The OP expects somehow for the server to prevent the client from = > exposing information when the server has no control over what the client = > sends. This simply is not possible and hence should not be expected. > > Even if the server were configured only with a ldaps:// listener, = > clients would not be precluded from sending a password to the server in = > the clear. A client could be told to connect to that listener and send = > a LDAP Simple Bind with password without ever attempting to start TLS. = > Sure, the server will error, but the password is exposed none the less. While this is true in general there still could be a benefit from disallowing connections without StartTLS at the server-side: Normally in a serious deployment there are integration tests done with client applications for which no real passwords are used. Disallowing non-protected connections would reveal misconfiguration immediately and the application can then be modified to do the right thing. Ciao, Michael.

1 0

Re: (ITS#6804) 'self' access modifier only works for first entry
by hyc＠symas.com 26 Jan '11

26 Jan '11

djpohly(a)gmail.com wrote: > Full_Name: Devin J. Pohly > Version: 2.4.23 > OS: Linux > URL: http://openldap.pastebin.com/gvswpxLX > Submission from: (NULL) (98.235.33.55) Thanks for the detailed report. This is now fixed in HEAD. > Description: > I have set up an LDAP directory which contains users and flat groups > (groupOfNames/member style). I want to use the access controls to only allow > users to see their own groups and membership, so I defined the following > controls: > > access to dn.onelevel="ou=group,o=org" attrs=entry > by dnattr=member read > access to dn.onelevel="ou=group,o=org" attrs=member > by dnattr=member selfread > > Steps to reproduce: > 1. Start a new instance of OpenLDAP with the slapd.conf file provided at > <http://openldap.pastebin.com/gvswpxLX> and an empty database. > 2. Get grouptest.ldif from<http://openldap.pastebin.com/X1DUyGmf> and add it to > the directory: > ldapadd -x -H $LDAPURI -D uid=admin,o=org -w admin -f grouptest.ldif > This creates two users, foo and bar, and two groups, g1 and g2. Each user is in > both groups. > 3. Compare the outputs of: > ldapsearch -x -H $LDAPURI -D uid=foo,ou=user,o=org -w foo -b ou=group,o=org > ldapsearch -x -H $LDAPURI -D uid=bar,ou=user,o=org -w bar -b ou=group,o=org > > Expected results: > Foo's query shows "member: foo" for both g1 and g2. Bar's query shows "member: > bar" for both g1 and g2. > > Actual results: > Foo's query shows "member: foo" for both g1 and g2. Bar's query does not show > any member attributes. > > Note: Changing the order in which the users are listed changes the behavior; > only the first user listed matches 'self'. Changing the 'selfread' privilege to > 'read' behaves correctly: both queries display both users' memberships in the > groups. So the problem lies somewhere in the way the 'self' modifier is > implemented. > -- -- 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#6805
by Kurt＠OpenLDAP.org 26 Jan '11

26 Jan '11

The OP expects somehow for the server to prevent the client from = exposing information when the server has no control over what the client = sends. This simply is not possible and hence should not be expected. Even if the server were configured only with a ldaps:// listener, = clients would not be precluded from sending a password to the server in = the clear. A client could be told to connect to that listener and send = a LDAP Simple Bind with password without ever attempting to start TLS. = Sure, the server will error, but the password is exposed none the less. As you indicate, the same issue exist in more robust clients as well. = It's quite hard to provide client configurability and prevention from = misconfiguration which lead to security issues concurrently. How is the = client software to know that StartTLS or ldaps:// was wanted with it = wasn't so configured? The best a robust client could do here is warn = the user of security concerns that arise from their configuration = choices. I would have no objection to adding such robustness to OpenLDAP command = line tools so long as such warnings were off by default. Kicking out = warnings as the default would likely break a lot of scripts which use = OpenLDAP command line tools. -- Kurt=

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by Kurt＠OpenLDAP.org 26 Jan '11

26 Jan '11

On Jan 26, 2011, at 11:23 AM, masarati(a)aero.polimi.it wrote: >>=20 >> On Jan 26, 2011, at 9:15 AM, masarati(a)aero.polimi.it wrote: >>=20 >>> The complexity of handling this nonsense in libldap seems not worth = the >>> effort; >>=20 >> Ando, you are too kind to refer this extension as 'nonsense'. It's = worse >> than nonsense, it's crap. >>=20 >> The spec you pointed at says: "LDAP servers often place limits on the >> maximum number of attribute values that can be retrieved in a single >> query." >=20 > I'd reword that as "One specific LDAP server places limits on the = maximum > number of attribute values that can be retrieved in a single query." >=20 >> The spec fails to say why would a server want to do that. I >> cannot think of any good reason to do precisely that. While I can >> understand a desire to place limits on what clients can retrieve, I = don't >> see why one would distinguish between a single query and a set of = queries. >> I can also see it desirable to allow a client to page through results >> (but that's a different matter, this is about forcing paging onto >> clients). >>=20 >> It is incredibly stupid to require clients to use multiple operations = to >> obtain information for which the protocol allowed to be fetched in a >> single operation, and this is why I refer to this as "crap". >=20 > :) >=20 >> A major problem with paging, whether server-forced or at = client-option, is >> result set coherency due to changes to the DIT between when various = page >> operations are obtain. This can lead to problems such a member of a = group >> not appearing in the results. While one might argue client might be = able >> to reasonable deal with coherency issues, most client developers = won't. >> This will lead to a range of security issues creeping into directory >> applications. >>=20 >> So while I don't generally oppose introduction of paging extensions = at the >> client option, I think the specifications should warn that the = clients >> using them need to be designed to handle data coherency issues. = However, >> most designers of such extensions seem to have put no thought into = this >> issue at all. >=20 > Well, I don't see paged results as a way to introduce more = inconsistency > than a regular search operation, since nowhere in the specs I see that = the > collection of the entries returned by a search are consistent with the > entries matching the search request at a specific time (e.g. when the > operation was initiated or so). As a consequence, clients need be = aware > of the fact that search results can be inherently inconsistent, paging = or > not. As LDAP is defined as an access protocol to an X.500 directory, it = inherits some data consistency expectations. In generally expected that = entry-level access have ACID properties. That is, each successful = modify operation creates a new DIT state and a read operation returns = information consistent with a particular state. That is, say the DIT = has state X and there is modify operation that produces state Y and a = concurrent issued read operation (and no other operations), the read = operation will return either state X or state Y depending on whether it = is processed before or after the modify operation. The read ought not = provide some intermediate state. A search operation acts upon a collection of entries, there is a = possibility of inconsistencies between different entries (but not within = them), especially in distributed DITs. However, as we're talking about values of an attribute of a particular = entry, this is a non-issue in this discussion.

1 0

ITS#6805
by masarati＠aero.polimi.it 26 Jan '11

26 Jan '11

I'd note that sending cleartext credentials is just wrong regardless of the ssf the server requires. OpenLDAP's ldapsearch assumes users know what they are doing. Actually, this client is mainly intended as a tool that allows to perform operations with as many parameter combinations as needed to test the functionalities of slapd. What you recommend would probably be appropriate for a "real life" client implementation. Moreover, the only way to test whether the security factor requested by the server is in place would require the client to attempt a simple bind with intentionally invalid credentials; considering slapd's possibility to configure security per-database, one would need to either use the "right" DN (thus exposing it), or a fake DN that for sure is within the same naming context, and incorrect credentials. I believe this amount of wisdom is beyond any "real life" client implementation. Of course I would not object to any patch for ldapsearch (actually, for all clients) that solves this problem in a general manner without requiring any user intervention. p.

1 0

(ITS#6805) ldapsearch can expose cleartext password needlessly
by leblanc＠math.toronto.edu 26 Jan '11

26 Jan '11

Full_Name: Emile LeBlanc Version: openldap-clients-2.3.43-12.el5_5.3.i386 OS: Red Hat Enterprise Linux 5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.100.68.202) I am running the latest version of ldapsearch (that comes with Red Hat Enterprise Linux 5.6) on my machine. If I run: ldapsearch -Z -W -LLL -D "uid=guest,ou=Unit,dc=math,dc=toronto,dc=edu" -H ldap://test.math.toronto.edu -x -b "dc=math,dc=toronto,dc=edu" "(uid=guest)" then the result is as I expect (after I type the passwd to the "Enter LDAP Password:" prompt). However if I remove the "-Z" flag and run: ldapsearch -W -LLL -D "uid=guest,ou=Unit,dc=math,dc=toronto,dc=edu" -H ldap://test.math.toronto.edu -x -b "dc=math,dc=toronto,dc=edu" "(uid=guest)" then, after typing the password I see: ldap_bind: Confidentiality required (13) additional info: confidentiality required This result was also expected since the ldap server has: security ssf=256 in the slapd.conf file. What was unexpected was that the password was sent in cleartext in the second "ldapsearch" command (I verified this with "wireshark", a network packet analyzer). It is true that I should use the "-Z" flag if I want encryption but I think that a simple error on the client end should not expose a password when the initial connection to a secured server could have been tried without transmitting the password to see if additional security was needed. Perhaps there is some good reason for the current behavior, but I wanted to make sure that people realized what was happening. Perhaps the performance hit my suggestion would entail is not worth it for other users. Thank you.

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by masarati＠aero.polimi.it 26 Jan '11

26 Jan '11

> > On Jan 26, 2011, at 9:15 AM, masarati(a)aero.polimi.it wrote: > >> The complexity of handling this nonsense in libldap seems not worth the >> effort; > > Ando, you are too kind to refer this extension as 'nonsense'. It's worse > than nonsense, it's crap. > > The spec you pointed at says: "LDAP servers often place limits on the > maximum number of attribute values that can be retrieved in a single > query." I'd reword that as "One specific LDAP server places limits on the maximum number of attribute values that can be retrieved in a single query." > The spec fails to say why would a server want to do that. I > cannot think of any good reason to do precisely that. While I can > understand a desire to place limits on what clients can retrieve, I don't > see why one would distinguish between a single query and a set of queries. > I can also see it desirable to allow a client to page through results > (but that's a different matter, this is about forcing paging onto > clients). > > It is incredibly stupid to require clients to use multiple operations to > obtain information for which the protocol allowed to be fetched in a > single operation, and this is why I refer to this as "crap". :) > A major problem with paging, whether server-forced or at client-option, is > result set coherency due to changes to the DIT between when various page > operations are obtain. This can lead to problems such a member of a group > not appearing in the results. While one might argue client might be able > to reasonable deal with coherency issues, most client developers won't. > This will lead to a range of security issues creeping into directory > applications. > > So while I don't generally oppose introduction of paging extensions at the > client option, I think the specifications should warn that the clients > using them need to be designed to handle data coherency issues. However, > most designers of such extensions seem to have put no thought into this > issue at all. Well, I don't see paged results as a way to introduce more inconsistency than a regular search operation, since nowhere in the specs I see that the collection of the entries returned by a search are consistent with the entries matching the search request at a specific time (e.g. when the operation was initiated or so). As a consequence, clients need be aware of the fact that search results can be inherently inconsistent, paging or not. > I do generally oppose introduction of non-truly optional extensions in > LDAP (and in other application protocols). One would think that a > requirement that extensions to a protocol be truely optional would go > without saying, but in IETF we actually found it necessary to explicitly > state this in the BCP governing LDAP extensions. > > That BCP will effectively stop non-truly optional extension proposal as > this from gaining Standard Track status in the IETF. > >> I think we might consider working this around in proxy backends >> (much like we did for unsolicited paged results response in back-meta, >> ITS#6664, which could be added to back-ldap as well). > > I would think it easier to reconfigure AD not to have the limits which > cause this sort of paging. Of course. The whole discussion about this issue (and others) and often the thrust that pushes the development of many features in the proxy backends (and other features, like slapo-rwm, slapo-translucent and more) is the practical impossibility to affect the configuration of one or more remote servers. p.

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by sgallagh＠redhat.com 26 Jan '11

26 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2011 12:15 PM, masarati(a)aero.polimi.it wrote: > > The complexity of handling this nonsense in libldap seems not worth the > effort; I think we might consider working this around in proxy backends > (much like we did for unsolicited paged results response in back-meta, > ITS#6664, which could be added to back-ldap as well). > > I don't think implementing something that requires a theoretically > unbounded number of nested search requests for each attribute value that > contains a range in each SearchResultEntry message makes sense. I didn't suggest that it should be enabled by default. I was looking for an option that could be set if a particular client needs it. > The parallel with referrals is not appropriate, since referrals are part > of LDAP specification; also, please note that automatic referral chasing > is strongly discouraged unless the transport layer is protected (Section 6 > of RFC 4511). Right, I really only meant in the broad sense of "You can enable this option if you really need it, knowing that there are risks and the potential for going through multiple additional requests". I just meant there was precedent for adding features that required extra trips to the server. I also fully agree that the range extension is a crime against decency, but unfortunately it's backed by the 800-pound gorilla that we can't just ignore. I think if we're stuck with it, it makes sense to put the code to deal with it in common OpenLDAP library code instead of forcing every consumer to rewrite it. Because at the end of the day, pretty much every LDAP client is going to need to be able to talk to Active Directory at some point. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Abw8ACgkQeiVVYja6o6MsjwCdFtTmbHk0yj16JT6Fz/ffU2QF bcQAmwaV/aWcJL4dk3QFtYgD11OvZ1QV =69z3 -----END PGP SIGNATURE-----

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by Kurt＠OpenLDAP.org 26 Jan '11

26 Jan '11

On Jan 26, 2011, at 9:15 AM, masarati(a)aero.polimi.it wrote: > The complexity of handling this nonsense in libldap seems not worth = the > effort; Ando, you are too kind to refer this extension as 'nonsense'. It's = worse than nonsense, it's crap. The spec you pointed at says: "LDAP servers often place limits on the = maximum number of attribute values that can be retrieved in a single = query." The spec fails to say why would a server want to do that. I = cannot think of any good reason to do precisely that. While I can = understand a desire to place limits on what clients can retrieve, I = don't see why one would distinguish between a single query and a set of = queries. I can also see it desirable to allow a client to page through = results (but that's a different matter, this is about forcing paging = onto clients). It is incredibly stupid to require clients to use multiple operations to = obtain information for which the protocol allowed to be fetched in a = single operation, and this is why I refer to this as "crap". A major problem with paging, whether server-forced or at client-option, = is result set coherency due to changes to the DIT between when various = page operations are obtain. This can lead to problems such a member of = a group not appearing in the results. While one might argue client = might be able to reasonable deal with coherency issues, most client = developers won't. This will lead to a range of security issues creeping = into directory applications. So while I don't generally oppose introduction of paging extensions at = the client option, I think the specifications should warn that the = clients using them need to be designed to handle data coherency issues. = However, most designers of such extensions seem to have put no thought = into this issue at all. I do generally oppose introduction of non-truly optional extensions in = LDAP (and in other application protocols). One would think that a = requirement that extensions to a protocol be truely optional would go = without saying, but in IETF we actually found it necessary to explicitly = state this in the BCP governing LDAP extensions. That BCP will effectively stop non-truly optional extension proposal as = this from gaining Standard Track status in the IETF. > I think we might consider working this around in proxy backends > (much like we did for unsolicited paged results response in back-meta, > ITS#6664, which could be added to back-ldap as well). I would think it easier to reconfigure AD not to have the limits which = cause this sort of paging. > I don't think implementing something that requires a theoretically > unbounded number of nested search requests for each attribute value = that > contains a range in each SearchResultEntry message makes sense. >=20 > The parallel with referrals is not appropriate, since referrals are = part > of LDAP specification; also, please note that automatic referral = chasing > is strongly discouraged unless the transport layer is protected = (Section 6 > of RFC 4511). >=20 > p.

1 0

ITS#5472
by masarati＠aero.polimi.it 26 Jan '11

26 Jan '11

For future reference, if needed: <http://msdn.microsoft.com/en-us/library/aa367017(v=vs.85).aspx>

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by masarati＠aero.polimi.it 26 Jan '11

26 Jan '11

> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'd like to reopen the discussion on this issue. We're hitting this same > problem with the SSSD when dealing with ActiveDirectory. It really > doesn't make sense to me that every consumer of the OpenLDAP libraries > should be required to reimplement this (admittedly incorrect) extension > to ActiveDirectory. > > As Petter suggested in his comment from April 21, 2008, ActiveDirectory > provides a server control to identify that the feature is in play. > > I feel that it would be beneficial to OpenLDAP's library consumers if > they handled range lookups automatically and internally, similar to the > way that referrals are chased. > > Consumers of the OpenLDAP API should be able to reliably assume that if > they ask for the set of values for an attribute of a completed request, > that they will get back all of the values. > > Please reconsider adding this support into OpenLDAP. The complexity of handling this nonsense in libldap seems not worth the effort; I think we might consider working this around in proxy backends (much like we did for unsolicited paged results response in back-meta, ITS#6664, which could be added to back-ldap as well). I don't think implementing something that requires a theoretically unbounded number of nested search requests for each attribute value that contains a range in each SearchResultEntry message makes sense. The parallel with referrals is not appropriate, since referrals are part of LDAP specification; also, please note that automatic referral chasing is strongly discouraged unless the transport layer is protected (Section 6 of RFC 4511). p.

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by sgallagh＠redhat.com 26 Jan '11

26 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to reopen the discussion on this issue. We're hitting this same problem with the SSSD when dealing with ActiveDirectory. It really doesn't make sense to me that every consumer of the OpenLDAP libraries should be required to reimplement this (admittedly incorrect) extension to ActiveDirectory. As Petter suggested in his comment from April 21, 2008, ActiveDirectory provides a server control to identify that the feature is in play. I feel that it would be beneficial to OpenLDAP's library consumers if they handled range lookups automatically and internally, similar to the way that referrals are chased. Consumers of the OpenLDAP API should be able to reliably assume that if they ask for the set of values for an attribute of a completed request, that they will get back all of the values. Please reconsider adding this support into OpenLDAP. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1AQQgACgkQeiVVYja6o6OACwCgg4t5Mm54X+ohYzhvG9fRBMTb gO4An0j/152a0PHFMTxTIuQ6kamlcsFb =3a3m -----END PGP SIGNATURE-----

1 0

Re: (ITS#6752) slapo-dynlist issues
by h.b.furuseth＠usit.uio.no 25 Jan '11

25 Jan '11

Charles Owens writes: > Would you characterize this as being a fix for stability, performance, > or some of both? Both, plus code cleanup with no user-visible effect. HEAD dynlist.c rev 1.72 = performance & cleanup, 1.73-1.74 = fixes, 1.75 = cleanup. If you're cherry-picking recent changes, you might as well grab the fix 1.76 for ITS#6758 as well. -- Hallvard

1 0

Re: (ITS#6803) LDAP Server
by quanah＠zimbra.com 24 Jan '11

24 Jan '11

--On Sunday, January 23, 2011 12:09 PM +0000 kashif.hameed(a)vopium.com wrote: > Full_Name: Kashif Hameed > Version: 2.3.8 > OS: centos5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.215.176.22) > > > I am installing and configuring ldap server with authentication samba but > i am unable to do this because with samba authentication it will return > error > > /usr/sbin/smbldap-passwd: user root doesn't exist > > so could any one help me regarding this issue The OpenLDAP project is not the Samba project. Samba questions should be directed to the Samba project. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6804) 'self' access modifier only works for first entry
by djpohly＠gmail.com 23 Jan '11

23 Jan '11

Full_Name: Devin J. Pohly Version: 2.4.23 OS: Linux URL: http://openldap.pastebin.com/gvswpxLX Submission from: (NULL) (98.235.33.55) Description: I have set up an LDAP directory which contains users and flat groups (groupOfNames/member style). I want to use the access controls to only allow users to see their own groups and membership, so I defined the following controls: access to dn.onelevel="ou=group,o=org" attrs=entry by dnattr=member read access to dn.onelevel="ou=group,o=org" attrs=member by dnattr=member selfread Steps to reproduce: 1. Start a new instance of OpenLDAP with the slapd.conf file provided at <http://openldap.pastebin.com/gvswpxLX> and an empty database. 2. Get grouptest.ldif from <http://openldap.pastebin.com/X1DUyGmf> and add it to the directory: ldapadd -x -H $LDAPURI -D uid=admin,o=org -w admin -f grouptest.ldif This creates two users, foo and bar, and two groups, g1 and g2. Each user is in both groups. 3. Compare the outputs of: ldapsearch -x -H $LDAPURI -D uid=foo,ou=user,o=org -w foo -b ou=group,o=org ldapsearch -x -H $LDAPURI -D uid=bar,ou=user,o=org -w bar -b ou=group,o=org Expected results: Foo's query shows "member: foo" for both g1 and g2. Bar's query shows "member: bar" for both g1 and g2. Actual results: Foo's query shows "member: foo" for both g1 and g2. Bar's query does not show any member attributes. Note: Changing the order in which the users are listed changes the behavior; only the first user listed matches 'self'. Changing the 'selfread' privilege to 'read' behaves correctly: both queries display both users' memberships in the groups. So the problem lies somewhere in the way the 'self' modifier is implemented.

1 0

(ITS#6803) LDAP Server
by kashif.hameed＠vopium.com 23 Jan '11

23 Jan '11

Full_Name: Kashif Hameed Version: 2.3.8 OS: centos5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.215.176.22) I am installing and configuring ldap server with authentication samba but i am unable to do this because with samba authentication it will return error /usr/sbin/smbldap-passwd: user root doesn't exist so could any one help me regarding this issue Thanks

1 0

Re: (ITS#6794) slapadd -q problems on glued databases
by Ralf Haferkamp 21 Jan '11

21 Jan '11

I just committed a fix and a testcase (to the regression directory) for this to HEAD. Please test.

1 0

(ITS#6802) Patch - Mozilla NSS - restart modules before NSS_Init after a fork()
by rmeggins＠redhat.com 21 Jan '11

21 Jan '11

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-secmod-restartmodules-20110… Submission from: (NULL) (76.113.111.209) NSS enforces the pkcs11 requirement that modules should be unloaded after a fork() - since there is no portable way to determine if NSS has been already initialized in a parent process, we just call SECMOD_RestartModules with force == FALSE before doing any NSS initialize calls - if the module has been unloaded due to a fork, it will be reloaded, otherwise, it is a no-op. These patch files are 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#6641) Syncrepl failure with 'overlay unique'
by hyc＠symas.com 20 Jan '11

20 Jan '11

ondrej.kuznik(a)acision.com wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/09/2010 03:50 PM, ondrej.kuznik(a)acision.com wrote: >> I have put a preliminary version of patches that modify the unique >> overlay here >> ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101109-unique_bypass_v1.tgz >> >> They add a new configuration attribute olcUniqueAllowManageBypass (it is >> prohibitively long for a name, though) that, if set to TRUE, triggers >> the uniqueness checks not to be performed if the operation has manage >> privilegies on the entry. There are three separate patches, >> configuration code regarding the new attribute, the checks in >> unique_{add,modify,modrdn} and manpage modifications. >> > After a conversation with Howard, I have modified the patches so that > the overlay check for the ManageDsaIt control instead. That control > should be set for each operation coming from replication. The patches > are here: > ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101202-unique_bypass_v2.tgz > > Is there anything else that comes to mind? I'm not sure it merits a config keyword. We already have instances where administrators are implicitly allowed to bypass rules that restrict normal users, and replication is obviously a system-level operation, not user level. -- -- 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#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by hyc＠symas.com 20 Jan '11

20 Jan '11

Chris Mikkelson wrote: > On Thu, Jan 13, 2011 at 12:30:32PM -0800, Howard Chu wrote: >> cmikk(a)qwest.net wrote: >>> Other than the patch I suggested (using the list head's >>> CSN value directly), I can think of two other approaches: >>> >>> 1) When adding an entry to the sessionlog, check >>> if sl_mincsn is empty. If it is, update sl_mincsn >>> to the new entry's CSN. >>> >>> 2) When initializing the sessionlog, set sl_mincsn >>> to the maximum contextCSN value of the underlying >>> database. >>> >>> #2 seems ideal from an efficiency standpoint, although it >>> differs from the algorithm the current code appears to be >>> intended to implement. >> >> We should have gone with #2. The problem scenario: > > The current code (in HEAD) covers the vast majority of > cases, but still has a hole which can come up quite often > in MMR + refreshOnly scenarios. The scenario: > > 1: provider 1, provider 2, and consumer all in sync. SID 1 CSN > is a few minutes old, SID 2 is a few hours old. Both sessionlogs > are empty with sl_mincsn set to the newest (provider 1) CSN value > 2: stop consumer > 3: write on provider 2 > 4: start consumer > > The provider will see that the consumer is out of date > wrt the SID 2 CSN and that the old value of the SID 2 CSN > predates sl_mincsn, so it will skip the session log. > > I think the following approach will cover this case: > > * sl_mincsn holds a CSN value for each SID Yeah, looks like we were headed there anyway. > * in syncprov_op_search, mincsn is compared to > the sl_mincsn value with the same SID The mincsn variable is no longer useful as-is. We need to compare the vector of CSNs from the cookie with the vector of CSNs in the provider. If any CSN in the consumer is older than the matching sl_mincsn then the log must be skipped. At this point there are a bunch of redundant O(N^2) walkthrus of the CSNs anyway, so getting rid of mincsn would be a good simplification. Since there may be many SIDs it would be better to sort both vectors and then walk thru them sequentially. > * when expiring log entries in in syncprov_add_slog, > the sl_mincsn value with the same SID as the expired > entry's CSN is set to the maximum of the two values. Yes. > If there is no matching SID in sl_mincsn, then: > > * in syncprov_op_search, this implies that the > mincsn's SID has been added to the provider's > configuration since startup or that the first > change recorded by that SID occurred since startup, > and thus the sessionlog contains sufficient > information > > * in syncprov_add_slog, sl_mincsn will need to > be expanded to hold the new SID's CSN > > Thoughts? Sounds right. -- -- 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#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by cmikk＠qwest.net 20 Jan '11

20 Jan '11

On Thu, Jan 13, 2011 at 12:30:32PM -0800, Howard Chu wrote: > cmikk(a)qwest.net wrote: > >Other than the patch I suggested (using the list head's > >CSN value directly), I can think of two other approaches: > > > > 1) When adding an entry to the sessionlog, check > > if sl_mincsn is empty. If it is, update sl_mincsn > > to the new entry's CSN. > > > > 2) When initializing the sessionlog, set sl_mincsn > > to the maximum contextCSN value of the underlying > > database. > > > >#2 seems ideal from an efficiency standpoint, although it > >differs from the algorithm the current code appears to be > >intended to implement. > > We should have gone with #2. The problem scenario: The current code (in HEAD) covers the vast majority of cases, but still has a hole which can come up quite often in MMR + refreshOnly scenarios. The scenario: 1: provider 1, provider 2, and consumer all in sync. SID 1 CSN is a few minutes old, SID 2 is a few hours old. Both sessionlogs are empty with sl_mincsn set to the newest (provider 1) CSN value 2: stop consumer 3: write on provider 2 4: start consumer The provider will see that the consumer is out of date wrt the SID 2 CSN and that the old value of the SID 2 CSN predates sl_mincsn, so it will skip the session log. I think the following approach will cover this case: * sl_mincsn holds a CSN value for each SID * in syncprov_op_search, mincsn is compared to the sl_mincsn value with the same SID * when expiring log entries in in syncprov_add_slog, the sl_mincsn value with the same SID as the expired entry's CSN is set to the maximum of the two values. If there is no matching SID in sl_mincsn, then: * in syncprov_op_search, this implies that the mincsn's SID has been added to the provider's configuration since startup or that the first change recorded by that SID occurred since startup, and thus the sessionlog contains sufficient information * in syncprov_add_slog, sl_mincsn will need to be expanded to hold the new SID's CSN Thoughts? -- Chris Mikkelson | It was mentioned on CNN that the prime number cmikk(a)qwest.net | discovered recently is four times bigger than the previous record. -- unknown

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by timo.aaltonen＠aalto.fi 20 Jan '11

20 Jan '11

On Thu, 20 Jan 2011, Howard Chu wrote: > timo.aaltonen(a)aalto.fi wrote: >> Hi >> >> Here's some information that Stephen asked would be of use. There is >> one forest, one domain, but three sites in the layout. The functional >> level of the forest and the domain is W2008, but the servers have 2008R2. >> >> And the full backtrace of the hung process: > >> #3 0x00007f8f652f3bcb in ldap_pvt_thread_mutex_lock >> (mutex=0x7f8f6553fc80) >> at /tmp/buildd/openldap-2.4.23/libraries/libldap_r/thr_posix.c:296 >> No locals. >> #4 0x00007f8f653010bf in ldap_sasl_interactive_bind_s (ld=0x2117c20, >> dn=0x0, >> mechs=0x210d530 "GSSAPI", serverControls=0x0, clientControls=0x0, >> flags=2, >> interact=0x7f8f61405120<sdap_sasl_interact>, defaults=0x2124a50) at >> sasl.c:426 >> rc = -1921681294 >> smechs = 0x0 > > This particular mutex seems kind of bogus to me; the code is from rev 1.31 in > June 2001. Perhaps back then it was unsafe to have multiple SASL operations > outstanding at once; I would expect that was only an issue in the Cyrus 1.5 > days and it should be safe now with Cyrus 2.x. We should probably just delete > this mutex. Ok, so by doing this: --- openldap-2.4.23.orig/libraries/libldap/sasl.c +++ openldap-2.4.23/libraries/libldap/sasl.c @@ -421,10 +421,11 @@ { int rc; char *smechs = NULL; - +/* #if defined( LDAP_R_COMPILE ) && defined( HAVE_CYRUS_SASL ) ldap_pvt_thread_mutex_lock( &ldap_int_sasl_mutex ); #endif +*/ #ifdef LDAP_CONNECTIONLESS if( LDAP_IS_UDP(ld) ) { /* Just force it to simple bind, silly to make the user -- .. the process doesn't hang anymore. But it still doesn't do what it's supposed to, but that could be a bug in SSSD. I'll investigate further. Thanks! -- Timo Aaltonen Systems Specialist, Aalto IT

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by hyc＠symas.com 20 Jan '11

20 Jan '11

hyc(a)symas.com wrote: > timo.aaltonen(a)aalto.fi wrote: >> Hi >> >> Here's some information that Stephen asked would be of use. There is >> one forest, one domain, but three sites in the layout. The functional >> level of the forest and the domain is W2008, but the servers have 2008R2. >> >> And the full backtrace of the hung process: > >> #3 0x00007f8f652f3bcb in ldap_pvt_thread_mutex_lock >> (mutex=0x7f8f6553fc80) >> at /tmp/buildd/openldap-2.4.23/libraries/libldap_r/thr_posix.c:296 >> No locals. >> #4 0x00007f8f653010bf in ldap_sasl_interactive_bind_s (ld=0x2117c20, >> dn=0x0, >> mechs=0x210d530 "GSSAPI", serverControls=0x0, clientControls=0x0, >> flags=2, >> interact=0x7f8f61405120<sdap_sasl_interact>, defaults=0x2124a50) at >> sasl.c:426 >> rc = -1921681294 >> smechs = 0x0 > > This particular mutex seems kind of bogus to me; the code is from rev 1.31 in > June 2001. Perhaps back then it was unsafe to have multiple SASL operations > outstanding at once; I would expect that was only an issue in the Cyrus 1.5 > days and it should be safe now with Cyrus 2.x. We should probably just delete > this mutex. > Although googling for "Cyrus sasl reentrancy" does not leave me with warm/fuzzy feelings. -- -- 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#6798) Mutex starvation on two-level referral for SASL connection
by hyc＠symas.com 20 Jan '11

20 Jan '11

timo.aaltonen(a)aalto.fi wrote: > Hi > > Here's some information that Stephen asked would be of use. There is > one forest, one domain, but three sites in the layout. The functional > level of the forest and the domain is W2008, but the servers have 2008R2. > > And the full backtrace of the hung process: > #3 0x00007f8f652f3bcb in ldap_pvt_thread_mutex_lock > (mutex=0x7f8f6553fc80) > at /tmp/buildd/openldap-2.4.23/libraries/libldap_r/thr_posix.c:296 > No locals. > #4 0x00007f8f653010bf in ldap_sasl_interactive_bind_s (ld=0x2117c20, > dn=0x0, > mechs=0x210d530 "GSSAPI", serverControls=0x0, clientControls=0x0, > flags=2, > interact=0x7f8f61405120<sdap_sasl_interact>, defaults=0x2124a50) at > sasl.c:426 > rc = -1921681294 > smechs = 0x0 This particular mutex seems kind of bogus to me; the code is from rev 1.31 in June 2001. Perhaps back then it was unsafe to have multiple SASL operations outstanding at once; I would expect that was only an issue in the Cyrus 1.5 days and it should be safe now with Cyrus 2.x. We should probably just delete this mutex. -- -- 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#6798) Mutex starvation on two-level referral for SASL connection
by timo.aaltonen＠aalto.fi 20 Jan '11

20 Jan '11

On Thu, 20 Jan 2011, Howard Chu wrote: > timo.aaltonen(a)aalto.fi wrote: >> Hi >> >> Here's some information that Stephen asked would be of use. There is >> one forest, one domain, but three sites in the layout. The functional >> level of the forest and the domain is W2008, but the servers have 2008R2. >> >> And the full backtrace of the hung process: > > Thanks, but this trace is from 2.4.21, which is obsolete. Please use the > current release (2.4.23) since the relevant code has changed. There is no > point in us spending time tracking down issues in non-existent code. Not true, I backported 2.4.23 from natty, and made it build in lucid pbuilder. nexus6 sssd # apt-cache policy libldap-2.4-2 libldap-2.4-2: Installed: 2.4.23-6ubuntu4aalto1 Candidate: 2.4.23-6ubuntu4aalto1 Version table: *** 2.4.23-6ubuntu4aalto1 0 100 /var/lib/dpkg/status 2.4.21-0ubuntu5.3 0 500 http://ubuntu.hut.fi/ubuntu/ lucid-updates/main Packages 2.4.21-0ubuntu5.2 0 500 http://ubuntu.hut.fi/ubuntu/ lucid-security/main Packages 2.4.21-0ubuntu5 0 500 http://ubuntu.hut.fi/ubuntu/ lucid/main Packages I believe there is no reason to rebuild sssd against that, since they are ABI compatible? -- Timo Aaltonen Systems Specialist, Aalto IT

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by hyc＠symas.com 20 Jan '11

20 Jan '11

hyc(a)symas.com wrote: > timo.aaltonen(a)aalto.fi wrote: >> Hi >> >> Here's some information that Stephen asked would be of use. There is >> one forest, one domain, but three sites in the layout. The functional >> level of the forest and the domain is W2008, but the servers have 2008R2. >> >> And the full backtrace of the hung process: > > Thanks, but this trace is from 2.4.21, which is obsolete. Please use the > current release (2.4.23) since the relevant code has changed. There is no > point in us spending time tracking down issues in non-existent code. And, one more time: please use a debug build, like I asked in my first reply. -- -- 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#6798) Mutex starvation on two-level referral for SASL connection
by hyc＠symas.com 20 Jan '11

20 Jan '11

timo.aaltonen(a)aalto.fi wrote: > Hi > > Here's some information that Stephen asked would be of use. There is > one forest, one domain, but three sites in the layout. The functional > level of the forest and the domain is W2008, but the servers have 2008R2. > > And the full backtrace of the hung process: Thanks, but this trace is from 2.4.21, which is obsolete. Please use the current release (2.4.23) since the relevant code has changed. There is no point in us spending time tracking down issues in non-existent code. -- -- 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#6798) Mutex starvation on two-level referral for SASL connection
by timo.aaltonen＠aalto.fi 20 Jan '11

20 Jan '11

Hi Here's some information that Stephen asked would be of use. There is one forest, one domain, but three sites in the layout. The functional level of the forest and the domain is W2008, but the servers have 2008R2. And the full backtrace of the hung process: #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 No locals. #1 0x00007f8f63ec05d9 in _L_lock_953 () from /lib/libpthread.so.0 No symbol table info available. #2 0x00007f8f63ec03fb in __pthread_mutex_lock (mutex=0x7f8f6553fc80) at pthread_mutex_lock.c:61 ignore1 = <value optimized out> ignore2 = 1700002944 ignore3 = -512 __PRETTY_FUNCTION__ = "__pthread_mutex_lock" type = <value optimized out> #3 0x00007f8f652f3bcb in ldap_pvt_thread_mutex_lock (mutex=0x7f8f6553fc80) at /tmp/buildd/openldap-2.4.23/libraries/libldap_r/thr_posix.c:296 No locals. #4 0x00007f8f653010bf in ldap_sasl_interactive_bind_s (ld=0x2117c20, dn=0x0, mechs=0x210d530 "GSSAPI", serverControls=0x0, clientControls=0x0, flags=2, interact=0x7f8f61405120 <sdap_sasl_interact>, defaults=0x2124a50) at sasl.c:426 rc = -1921681294 smechs = 0x0 #5 0x00007f8f6140888d in sdap_rebind_proc (ldap=0x2117c20, url=0x2125a00 "ldap://DomainDnsZones.domain.com/DC=DomainDnsZones,DC=domain,DC=com", request=<value optimized out>, msgid=<value optimized out>, params=<value optimized out>) at src/providers/ldap/sdap_async_connection.c:1637 p = <value optimized out> sasl_mech = <value optimized out> user_dn = <value optimized out> password = {bv_len = 0, bv_val = 0x0} ctrls = {0x0, 0x0} tmp_ctx = <value optimized out> ret = <value optimized out> __FUNCTION__ = "sdap_rebind_proc" #6 0x00007f8f65310a46 in ldap_new_connection (ld=0x2117c20, srvlist=0x7fffdebf22f8, use_ldsb=0, connect=1, bind=0x7fffdebf22b0) at request.c:518 srvfunc = 0x2122da0 err = 0 savedefconn = 0x21208d0 lc = 0x21227c0 async = 0 __PRETTY_FUNCTION__ = "ldap_new_connection" #7 0x00007f8f6530fdf0 in ldap_send_server_request (ld=0x2117c20, ber=0x2122760, msgid=8, parentreq=0x21304f0, srvlist=0x7fffdebf22f8, lc=0x0, bind=0x7fffdebf22b0) at request.c:211 lr = 0x63 incparent = 1 rc = 1697594315 #8 0x00007f8f653125dc in ldap_chase_v3referrals (ld=0x2117c20, lr=0x21304f0, refs=0x0, sref=1, errstrp=0x2130520, hadrefp=0x7fffdebf24f8) at request.c:1211 unfollowed = 0x0 unfollowedcnt = 0 origreq = 0x21304f0 srv = 0x2125a60 ber = 0x2122760 refarray = 0x2122720 lc = 0x0 rc = 0 count = 0 i = 0 j = 0 id = 8 rinfo = {ri_msgid = 5, ri_request = 99, ri_url = 0x2125a00 "ldap://DomainDnsZones.domain.com/DC=DomainDnsZones,DC=domain,DC=com"} #9 0x00007f8f652f6165 in try_read1msg (ld=0x2117c20, msgid=7, all=1, lc=0x2117760, result=0x7fffdebf26b0) at result.c:708 refs = 0x2122720 ber = 0x212e910 newmsg = 0x2117c20 l = 0x2124140 prev = 0x7debf25e0 id = 5 idx = 0 tag = 115 len = 76 foundit = 0 lr = 0x21304f0 tmplr = 0x7f8f6531039d dummy_lr = {lr_msgid = 0, lr_status = 0, lr_refcnt = 0, lr_outrefcnt = 0, lr_abandoned = 0, lr_origid = 0, lr_parentcnt = 0, lr_res_msgtype = 0, lr_res_errno = 0, lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x0, lr_conn = 0x0, lr_dn = {bv_len = 0, bv_val = 0x0}, lr_parent = 0x0, lr_child = 0x0, lr_refnext = 0x0, lr_prev = 0x0, lr_next = 0x0} tmpber = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 0, ber_len = 85, ber_usertag = 0, ber_buf = 0x2131cd0 "\002\001\005s\204", ber_ptr = 0x2131d25 "", ber_end = 0x2131d25 "", ber_sos_ptr = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} rc = -2 refer_cnt = 0 hadref = 0 simple_request = 0 err = 1 lderr = 0 tmp = 0x0 chain_head = 0x0 moremsgs = 0 isv2 = 0 __PRETTY_FUNCTION__ = "try_read1msg" #10 0x00007f8f652f571b in wait4msg (ld=0x2117c20, msgid=7, all=1, timeout=0x7fffdebf25b0, result=0x7fffdebf26b0) at result.c:390 lnext = 0x2117760 lc_ready = 1 rc = -2 tv = {tv_sec = 6, tv_usec = 0} tv0 = {tv_sec = 6, tv_usec = 0} start_time_tv = {tv_sec = 1295533580, tv_usec = 63738} tvp = 0x7fffdebf25b0 lc = 0x2117760 __PRETTY_FUNCTION__ = "wait4msg" #11 0x00007f8f652f4ddf in ldap_result (ld=0x2117c20, msgid=7, all=1, timeout=0x0, result=0x7fffdebf26b0) at result.c:120 rc = 1227 __PRETTY_FUNCTION__ = "ldap_result" #12 0x00007f8f65300a06 in ldap_sasl_bind_s (ld=0x2117c20, dn=0x0, mechanism=0x7f8f5ffe894c "GSSAPI", cred=0x7fffdebf2740, sctrls=0x0, cctrls=0x0, servercredp=0x7fffdebf2758) at sasl.c:194 rc = 0 msgid = 7 result = 0x0 scredp = 0x0 #13 0x00007f8f652fce5b in ldap_int_sasl_bind (ld=0x2117c20, dn=0x0, mechs=0x210d530 "GSSAPI", sctrls=0x0, cctrls=0x0, flags=2, interact=0x7f8f61405120 <sdap_sasl_interact>, defaults=0x21170b0) at cyrus.c:535 scred = 0x0 credlen = 32767 data = 0x8d757872de362e00 <Address 0x8d757872de362e00 out of bounds> mech = 0x7f8f5ffe894c "GSSAPI" pmech = 0x7f8f5ffe894c "GSSAPI" saslrc = 1 rc = 0 ssf = 0x0 ctx = 0x2127380 oldctx = 0x0 prompts = 0x0 credlen = 1202 ccred = {bv_len = 1202, bv_val = 0x2125540 "`\202\004\256\006\t*\206H\206\367\022\001\002\002\001"} sd = 23 ssl = 0x0 #14 0x00007f8f6530120f in ldap_sasl_interactive_bind_s (ld=0x2117c20, dn=0x0, mechs=0x210d530 "GSSAPI", serverControls=0x0, clientControls=0x0, flags=2, interact=0x7f8f61405120 <sdap_sasl_interact>, defaults=0x21170b0) at sasl.c:464 rc = -1921681294 smechs = 0x0 #15 0x00007f8f6140888d in sdap_rebind_proc (ldap=0x2117c20, url=0x2126270 "ldap://ForestDnsZones.domain.com/DC=ForestDnsZones,DC=domain,DC=com", request=<value optimized out>, msgid=<value optimized out>, params=<value optimized out>) at src/providers/ldap/sdap_async_connection.c:1637 p = <value optimized out> sasl_mech = <value optimized out> user_dn = <value optimized out> password = {bv_len = 0, bv_val = 0x0} ctrls = {0x0, 0x0} tmp_ctx = <value optimized out> ret = <value optimized out> __FUNCTION__ = "sdap_rebind_proc" #16 0x00007f8f65310a46 in ldap_new_connection (ld=0x2117c20, srvlist=0x7fffdebf2bd8, use_ldsb=0, connect=1, bind=0x7fffdebf2b90) at request.c:518 srvfunc = 0x2122190 err = 0 savedefconn = 0x2117760 lc = 0x21208d0 async = 0 __PRETTY_FUNCTION__ = "ldap_new_connection" #17 0x00007f8f6530fdf0 in ldap_send_server_request (ld=0x2117c20, ber=0x21206e0, msgid=6, parentreq=0x21304f0, srvlist=0x7fffdebf2bd8, lc=0x0, bind=0x7fffdebf2b90) at request.c:211 lr = 0x63 incparent = 1 rc = 1697594315 #18 0x00007f8f653125dc in ldap_chase_v3referrals (ld=0x2117c20, lr=0x21304f0, refs=0x0, sref=1, errstrp=0x2130520, hadrefp=0x7fffdebf2dd8) at request.c:1211 unfollowed = 0x0 unfollowedcnt = 0 origreq = 0x21304f0 srv = 0x2116b40 ber = 0x21206e0 refarray = 0x212b470 lc = 0x0 rc = 0 count = 0 i = 0 j = 0 id = 6 rinfo = {ri_msgid = 5, ri_request = 99, ri_url = 0x2126270 "ldap://ForestDnsZones.domain.com/DC=ForestDnsZones,DC=domain,DC=com"} #19 0x00007f8f652f6165 in try_read1msg (ld=0x2117c20, msgid=-1, all=0, lc=0x2117760, result=0x7fffdebf2f68) at result.c:708 refs = 0x212b470 ber = 0x2122580 newmsg = 0x7f8f674287b8 l = 0x7fffdebf2ef0 prev = 0x7f8f67460cd8 id = 5 idx = 0 tag = 115 len = 76 foundit = 0 lr = 0x21304f0 tmplr = 0x100000000 dummy_lr = {lr_msgid = 0, lr_status = 0, lr_refcnt = 0, lr_outrefcnt = 0, lr_abandoned = 0, lr_origid = 0, lr_parentcnt = 0, lr_res_msgtype = 0, lr_res_errno = 0, lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x0, lr_conn = 0x0, lr_dn = {bv_len = 0, bv_val = 0x0}, lr_parent = 0x0, lr_child = 0x0, lr_refnext = 0x0, lr_prev = 0x0, lr_next = 0x0} tmpber = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 0, ber_len = 85, ber_usertag = 0, ber_buf = 0x2125410 "\002\001\005s\204", ber_ptr = 0x2125465 "", ber_end = 0x2125465 "", ber_sos_ptr = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} rc = -2 refer_cnt = 0 hadref = 0 simple_request = 0 err = 0 lderr = 32655 tmp = 0x0 chain_head = 0x0 moremsgs = 0 isv2 = 0 __PRETTY_FUNCTION__ = "try_read1msg" #20 0x00007f8f652f571b in wait4msg (ld=0x2117c20, msgid=-1, all=0, timeout=0x7fffdebf2f50, result=0x7fffdebf2f68) at result.c:390 lnext = 0x7f8f6742f000 lc_ready = 1 rc = -2 tv = {tv_sec = 0, tv_usec = 0} tv0 = {tv_sec = 0, tv_usec = 0} start_time_tv = {tv_sec = 1295533580, tv_usec = 60251} tvp = 0x7fffdebf2e90 lc = 0x2117760 __PRETTY_FUNCTION__ = "wait4msg" #21 0x00007f8f652f4ddf in ldap_result (ld=0x2117c20, msgid=-1, all=0, timeout=0x7fffdebf2f50, result=0x7fffdebf2f68) at result.c:120 rc = 32655 __PRETTY_FUNCTION__ = "ldap_result" #22 0x00007f8f613f7cb4 in sdap_process_result (ev=0x20f11f0, pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:178 sh = 0x21176f0 no_timeout = {tv_sec = 0, tv_usec = 0} te = <value optimized out> msg = <value optimized out> ret = <value optimized out> __FUNCTION__ = "sdap_process_result" #23 0x00007f8f66e3077e in ?? () from /usr/lib/libtevent.so.0 No symbol table info available. #24 0x00007f8f66e2d9f0 in _tevent_loop_once () from /usr/lib/libtevent.so.0 No symbol table info available. #25 0x00007f8f66e2da5b in ?? () from /usr/lib/libtevent.so.0 No symbol table info available. #26 0x0000000000431e51 in server_loop (main_ctx=0x20f2360) at src/util/server.c:526 No locals. #27 0x000000000040f8bb in main (argc=5, argv=<value optimized out>) at src/providers/data_provider_be.c:1333 opt = <value optimized out> pc = <value optimized out> be_domain = 0x20e8490 "DOMAIN" srv_name = <value optimized out> conf_entry = <value optimized out> main_ctx = 0x20f2360 ret = 0 long_options = {{longName = 0x0, shortName = 0 '\000', argInfo = 4, arg = 0x644d00, val = 0, descrip = 0x436e64 "Help options:", argDescrip = 0x0}, { longName = 0x436e72 "debug-level", shortName = 100 'd', argInfo = 2, arg = 0x644de0, val = 0, descrip = 0x436e43 "Debug level", argDescrip = 0x0}, { longName = 0x436e7e "debug-to-files", shortName = 102 'f', argInfo = 0, arg = 0x644de4, val = 0, descrip = 0x437ad8 "Send the debug output to files instead of stderr", argDescrip = 0x0}, {longName = 0x436e8d "debug-timestamps", shortName = 0 '\000', argInfo = 2, arg = 0x644cc0, val = 0, descrip = 0x436e4f "Add debug timestamps", argDescrip = 0x0}, {longName = 0x438458 "domain", shortName = 0 '\000', argInfo = 1, arg = 0x7fffdebf31d8, val = 0, descrip = 0x437b10 "Domain of the information provider (mandatory)", argDescrip = 0x0}, {longName = 0x0, shortName = 0 '\000', argInfo = 0, arg = 0x0, val = 0, descrip = 0x0, argDescrip = 0x0}} __FUNCTION__ = "main" -- Timo Aaltonen Systems Specialist, Aalto IT

1 0

Re: (ITS#6801) New feature, add subtree-include support in meta backend
by masarati＠aero.polimi.it 20 Jan '11

20 Jan '11

jorge.perez.burgos(a)ericsson.com wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.21 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.235.15.243) > > > I'd suggest to introduce a "subtree-include" directive, mutually exclusive with > "subtree-exclude", with different syntaxes, like: > > "[dn[.<style>]:]<pattern>" > > where <style> can be "subtree" or "regex" (other styles like "exact", > "onelevel", "subordinate" could make sense but would be of limited usefulness); > so, for example > > "dn.subtree:<dn>" ("dn.subtree" implicit for backward compatibility) > "dn.regex:<pattern>" > > The "dn.<style>:" prefix is consistent with other features like ACLs, limits and > so. There's ITS#5877 open about making this uniform across slapd for all > features. > > Multiple patterns could be defined; the first that matches would stop execution. > If configured as "subtree-exclude", a match would qualify the target as > "non-candidate" (current behavior for "subtree-exclude"). If configured as > "subtree-include", a match would qualify the target as "candidate". Jorge and I discussed this off-line; suggestions are welcome, otherwise I'd implement it this way right now with ad-hoc code, and eventually turn it into a generally useful feature that could be reused in ACLs, limits, authz, and in other to-be-defined features. p.

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by h.b.furuseth＠usit.uio.no 20 Jan '11

20 Jan '11

hyc(a)symas.com writes: > Looks like libldap needs to be changed to actually record the tag of the > outgoing requests. (It ought to do so anyway, and probably should return a > ProtocolError result if it receives a response message whose tag doesn't match > its request type.) Yes. OpenLDAP is too trunsting of incoming PDUs to be valid. ...as an option, if this would be noticeable for a lot of users. Users who Just Want Their Programs To Work without OpenLDAP breaking them, and won't be interested in "finger-pointing" against someone else's servers. -- Hallvard

1 0

(ITS#6801) New feature, add subtree-include support in meta backend
by jorge.perez.burgos＠ericsson.com 20 Jan '11

20 Jan '11

Full_Name: Jorge Perez Burgos Version: 2.4.21 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) I'd suggest to introduce a "subtree-include" directive, mutually exclusive with "subtree-exclude", with different syntaxes, like: "[dn[.<style>]:]<pattern>" where <style> can be "subtree" or "regex" (other styles like "exact", "onelevel", "subordinate" could make sense but would be of limited usefulness); so, for example "dn.subtree:<dn>" ("dn.subtree" implicit for backward compatibility) "dn.regex:<pattern>" The "dn.<style>:" prefix is consistent with other features like ACLs, limits and so. There's ITS#5877 open about making this uniform across slapd for all features. Multiple patterns could be defined; the first that matches would stop execution. If configured as "subtree-exclude", a match would qualify the target as "non-candidate" (current behavior for "subtree-exclude"). If configured as "subtree-include", a match would qualify the target as "candidate".

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by hyc＠symas.com 20 Jan '11

20 Jan '11

sgallagh(a)redhat.com wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/19/2011 11:39 AM, masarati(a)aero.polimi.it wrote: >>> Full_Name: Stephen Gallagher >>> Version: 2.4.21-0ubuntu5.2 >> >> I think this issue report is obsoleted by ITS#6510 (released with OL >> 2.4.22), which prevents binds from returning referrals. Please upgrade >> and re-check. > > Upgraded to 2.4.23 and the same behavior occurs. I note in issue 6510 > that it was suggested that nested mutexes could be used to resolve this. > Perhaps we should revisit that. No. Nested mutexes are non-portable, and as already discussed in #6510, it is incorrect to process referrals returned in response to Bind requests. > As you can see from our backtrace, this is actually occurring during the > processing of ldap_result(). We're handling a rebind as ldap_result > travels through a series of referrals. Most likely your server is not using an actual Bind Response tag in its response message. It would be good if you could run this using a debug build (no optimization, full debug symbols present) and examine the tag that was parsed from the referral result. Looks like libldap needs to be changed to actually record the tag of the outgoing requests. (It ought to do so anyway, and probably should return a ProtocolError result if it receives a response message whose tag doesn't match its request type.) -- -- 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#6758) Cleaning up SlapReply usage
by h.b.furuseth＠usit.uio.no 19 Jan '11

19 Jan '11

I wrote: > In addition to the issues listed in my last message, this ITS depends > on these: [ITS#6763,#6776#6760]. Sorry, that was quite wrong. The changes done so far can stand alone, I've tried hard for that. Taking this ITS _further_ depends on those ITSes. But those ITSes are safest to tackle after the changes I've done so far. I've done this ITS backwards after some IRC miscommunication and by sitting too close to the code: First commit a huge patch to clean up SlapReply, then explain why. Sorry about that. I intended to get it done for 2.4.24, but when Howard balked at this approach I expect I instead ended up complicating HEAD->RE24 merges. So to explain better: This is ITS#5340 with a better name. See http://www.openldap.org/its/?findid=5340#followup16 - 18 which actually explains most of the rationale for these changes: "I'm a bit nervous about doing more than minimal fixes to this until we do something major, because it's so broken. (...) [Howard suggested] code which puts something into a SlapReply should ensure it's taken out again. (...) I think that's not the right fix because it's the most fragile solution: Practically every module which depends on it can break if some other module gets it wrong. OTOH, modules can't just reset SlapReply since some of it is input values to op_*() (...)" SlapReply is so broken and confusing that for 3 years I've not dared to do the obvious fixes to ITS#5340. Early on I kept prompting others who understood slapd better than me to take on #5430, but nothing happened. So now I've "done something major": Cleaned up SlapReply enough that it's no longer an act of bravery to take on the original issues. Most of the changes are a preliminary cleanup for going for the original ITS#5340 fixes (obeying the flags). elsewhere: By the original design, it's not a bug for an op_*() function to expect an incoming SlapReply to be clean, nor to output a "dirty" SlapReply, so it' has got to be wrong to reuse a SlapReply without cleaning it up. So I've taken a simpler and more robust approach this time, adding bigger but more trivial changes: In addition to cleaning up some flags, I've killed most cases of SlapReply reuse, which also isolates what damage one module can do to another through SlapReply. Even if they are third-party overlays where the first is broken because it accurately copied what OpenLDAP's overlays were doing:( I've also mostly fixed rs.sr_type. That one was almost as broken, somewhat in the spirit of this awful and confusing idea in result.c: /* FIXME: I think rs->sr_type should be explicitly set to * REP_SEARCH here. That's what it was when we entered this * function. send_ldap_error may have changed it, but we * should set it back so that the cleanup functions know * what they're doing. */ No. If something set rs.sr_type = REP_INTERMEDIATE, result.c should not tell its caller that OID rs.sr_rspoid is an entry, rs.sr_entry. As for user-visible issues the cleanup caught: Half of my December and January ITSes came from this effort. Some minor, some bigger. Generally issues somewhat out of scope of what I was doing in this ITS. Howard asked if all these changes fixed any crashes. Thinking it over, I've had few crashes because of this mess, and I have had a hard time trying to remember which ones. I've had many crashes in the truckload of asserts I added in my private code, which pointed out these ITSes and how to clean up. I could not have found the ITSes before the cleanup, since the asserts then brought down slapd in an instant. Also I've broken slapd a number of times by attempting "obvious" fixes before cleaning up, because slapd is more creative than me about reusing SlapReply strangely. Like pcache.c which reused a Search SlapReply with an entry in it for be_modify() and expected the entry to still be there after the modify:-( Looks like a good candidate for trying to construct a pre-cleanup crash, if I ever find time to try: Find a way to feed that SlapReply to something which reuses it for a Search or an Intermediate Response, thus overwriting the entry sitting in the Modify SlapReply. That kind if thing is why I'm much more eager to get the initial cleanup into RE24 than to get the final entry leak fixes etc into RE24. After the cleanup, there should only be an entry in there if sr_type is REP_SEARCH/REP_SEARCHREF, not also REP_RESULT/REP_GLUE_RESULT as before. ITSes: ITS#6760 slapo-rwm broken entry handling ITS#6752 slapo-dynlist issues [+ related non-SlapReply issues] ITS#6746, #6763 entry/control leaks [+ related non-SlapReply issues] My commits using rs_flush_entry() & co have fixed some other entry leaks or potential leaks. Some modules - in particular BDB - catch potential leaks of their entries. Others do not, giving us memory leaks. ITS#6731, #6748 used scrambled sr_text on an exited function's stack. ITS#6774, ITS#6785, some of my back-config commits: sr_text/sr_matched sent with sr_err=LDAP_SUCCESS, or related to another error than sr_err. Browsing 2.4.24 patches, an earlier cleanup would have caught #6633 (slapd-bdb error propagation) - my asserts with test047 catch sr_text != NULL when sr_err == 0 - and likely #6629 (freeing controls). -- Regards, Hallvard

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by sgallagh＠redhat.com 19 Jan '11

19 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/19/2011 11:39 AM, masarati(a)aero.polimi.it wrote: >> Full_Name: Stephen Gallagher >> Version: 2.4.21-0ubuntu5.2 > > I think this issue report is obsoleted by ITS#6510 (released with OL > 2.4.22), which prevents binds from returning referrals. Please upgrade > and re-check. Upgraded to 2.4.23 and the same behavior occurs. I note in issue 6510 that it was suggested that nested mutexes could be used to resolve this. Perhaps we should revisit that. As you can see from our backtrace, this is actually occurring during the processing of ldap_result(). We're handling a rebind as ldap_result travels through a series of referrals. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk03WlYACgkQeiVVYja6o6PiXACgmykXZhhKZkixweJTb/qIVPAc DMAAn2GHK7wu3nC5mkcYq7jI2f13Ql+N =rj7f -----END PGP SIGNATURE-----

1 0

Re: (ITS#5421) slapd vs LDAP_R_COMPILE
by hyc＠symas.com 19 Jan '11

19 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > Taken to this thread: > > http://www.openldap.org/lists/openldap-devel/201011/msg00013.html > librewrite& co vs. logging& ldap-int.h > > Since this ITS now depends on the ldap_debug hack in ldap_log.h, > I'm removing some unnecessary '#include<ldap_log.h>'s for clarity. > I've committed the fix suggested in the email linked above. -- -- 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#6800) back-meta: pseudorootdn & pseudorootpw deprecated
by masarati＠aero.polimi.it 19 Jan '11

19 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.31.111) Submitted by: ando back-meta's man page lists pseudoroot{dn,pw} as deprecated configuration statements; move them to a separate block. p.

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by masarati＠aero.polimi.it 19 Jan '11

19 Jan '11

> Full_Name: Stephen Gallagher > Version: 2.4.21-0ubuntu5.2 I think this issue report is obsoleted by ITS#6510 (released with OL 2.4.22), which prevents binds from returning referrals. Please upgrade and re-check. p.

1 0

(ITS#6799) back-meta may erroneously consider as candidates targets outside the scope of a search
by masarati＠aero.polimi.it 19 Jan '11

19 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.31.111) Submitted by: ando meta_back_is_candidate() marks as candidate any target whose suffix is subordinate to the search request when the request has "subtree" scope. This in principle can give false positives and could also give false negatives. However, that piece of code is always exploited with a "subtree" scope, regardless of the actual scope of the search. As a consequence, only false positives can occur (which is harmless but may result in unnecessary activity). The function meta_back_is_candidate() has been fixed to correctly manage all conditions; when called during a search request, the actual scope is used, to make sure only actual candidates are considered by search operations. p.

1 0

(ITS#6798) Mutex starvation on two-level referral for SASL connection
by sgallagh＠redhat.com 19 Jan '11

19 Jan '11

Full_Name: Stephen Gallagher Version: 2.4.21-0ubuntu5.2 OS: Ubuntu 10.04 URL: Submission from: (NULL) (98.110.239.235) This was discovered by a user of SSSD. When referrals are enabled with LDAP_OPT_REFERRALS on, SSSD has a rebind procedure set up to handle authenticating to the new server. This seems to work fine when we're dealing with a simple bind, but when we attempt to use SASL bind (for Kerberos-based GSSAPI authentication), we discovered a problem. Our rebind procedure calls ldap_sasl_interactive_bind_s() with LDAP_SASL_QUIET. This arrangement works fine for a single referral, however if the server has nested referrals (say, entry1 refers to entry2 which refers to entry3 on another server) then we hit a deadlock condition. Attaching gdb, we see the backtrace included at the bottom of this message. What appears to be happening is that for the first ldap_sasl_interactive_bind_s(), openldap is locking a mutex, and when it is called a second time it's attempting to lock that same mutex that has not yet been released. Backtrace: #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 No locals. #1 0x00007f48285975d9 in _L_lock_953 () from /lib/libpthread.so.0 No symbol table info available. #2 0x00007f48285973fb in __pthread_mutex_lock (mutex=0x7f4829c05980) at pthread_mutex_lock.c:61 ignore1 = <value optimized out> ignore2 = 700471680 ignore3 = -512 __PRETTY_FUNCTION__ = "__pthread_mutex_lock" type = <value optimized out> #3 0x00007f48299d3e4e in ldap_sasl_interactive_bind_s () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #4 0x00007f4825ae00fd in sdap_rebind_proc (ldap=0x2241b80, url=0x2250220 "ldap://DomainDnsZones.org.example.com/DC=DomainDnsZones,DC=org,DC=example,D…", request=<value optimized out>, msgid=<value optimized out>, params=<value optimized out>) at src/providers/ldap/sdap_async_connection.c:1624 p = <value optimized out> sasl_mech = <value optimized out> user_dn = <value optimized out> password = {bv_len = 0, bv_val = 0x0} ctrls = {0x0, 0x0} tmp_ctx = <value optimized out> ret = <value optimized out> __FUNCTION__ = "sdap_rebind_proc" #5 0x00007f48299df6d1 in ldap_new_connection () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #6 0x00007f48299e0523 in ldap_send_server_request () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #7 0x00007f48299e11cd in ldap_chase_v3referrals () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #8 0x00007f48299cbf95 in ?? () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #9 0x00007f48299ccc2d in ldap_result () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #10 0x00007f48299d4788 in ldap_sasl_bind_s () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #11 0x00007f48299d1751 in ldap_int_sasl_bind () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #12 0x00007f48299d3ea8 in ldap_sasl_interactive_bind_s () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #13 0x00007f4825ae00fd in sdap_rebind_proc (ldap=0x2241b80, url=0x225bc20 "ldap://ForestDnsZones.org.example.com/DC=ForestDnsZones,DC=org,DC=example,D…", request=<value optimized out>, msgid=<value optimized out>, params=<value optimized out>) at src/providers/ldap/sdap_async_connection.c:1624 p = <value optimized out> sasl_mech = <value optimized out> user_dn = <value optimized out> password = {bv_len = 0, bv_val = 0x0} ctrls = {0x0, 0x0} tmp_ctx = <value optimized out> ret = <value optimized out> __FUNCTION__ = "sdap_rebind_proc" #14 0x00007f48299df6d1 in ldap_new_connection () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #15 0x00007f48299e0523 in ldap_send_server_request () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #16 0x00007f48299e11cd in ldap_chase_v3referrals () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #17 0x00007f48299cbf95 in ?? () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #18 0x00007f48299ccc2d in ldap_result () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #19 0x00007f4825acfcb4 in sdap_process_result (ev=0x221b1f0, pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:178 sh = 0x2241650 no_timeout = {tv_sec = 0, tv_usec = 0} te = <value optimized out> msg = <value optimized out> ret = <value optimized out> __FUNCTION__ = "sdap_process_result" #20 0x00007f482b4f1825 in ?? () from /usr/lib/libtevent.so.0 No symbol table info available. #21 0x00007f482b4f363b in ?? () from /usr/lib/libtevent.so.0 No symbol table info available. #22 0x00007f482b4f09f0 in _tevent_loop_once () from /usr/lib/libtevent.so.0 No symbol table info available. #23 0x00007f482b4f0a5b in ?? () from /usr/lib/libtevent.so.0 No symbol table info available. #24 0x0000000000431e51 in server_loop (main_ctx=0x221c360) at src/util/server.c:526 No locals. #25 0x000000000040f8bb in main (argc=5, argv=<value optimized out>) at src/providers/data_provider_be.c:1333 opt = <value optimized out> pc = <value optimized out> be_domain = 0x2212490 "AALTO" srv_name = <value optimized out> conf_entry = <value optimized out> main_ctx = 0x221c360 ret = 0 long_options = {{longName = 0x0, shortName = 0 '\000', argInfo = 4, arg = 0x644d00, val = 0, descrip = 0x436e64 "Help options:", argDescrip = 0x0}, { longName = 0x436e72 "debug-level", shortName = 100 'd', argInfo = 2, arg = 0x644de0, val = 0, descrip = 0x436e43 "Debug level", argDescrip = 0x0}, { longName = 0x436e7e "debug-to-files", shortName = 102 'f', argInfo = 0, arg = 0x644de4, val = 0, descrip = 0x437ad8 "Send the debug output to files instead of stderr", argDescrip = 0x0}, {longName = 0x436e8d "debug-timestamps", shortName = 0 '\000', argInfo = 2, arg = 0x644cc0, val = 0, descrip = 0x436e4f "Add debug timestamps", argDescrip = 0x0}, {longName = 0x438458 "domain", shortName = 0 '\000', argInfo = 1, arg = 0x7fffe703f208, val = 0, descrip = 0x437b10 "Domain of the information provider (mandatory)", argDescrip = 0x0}, {longName = 0x0, shortName = 0 '\000', argInfo = 0, arg = 0x0, val = 0, descrip = 0x0, argDescrip = 0x0}} __FUNCTION__ = "main"

1 0

Re: (ITS#6796) overlay proxycache
by masarati＠aero.polimi.it 19 Jan '11

19 Jan '11

Apparently it works. p. ÷ÁÒÎÁËÏ× ëÉÒÉÌÌ wrote: > It works!!! > > 18.01.2011, 22:47, masarati(a)aero.polimi.it: >>> Full_Name: Varnakov Kiril >>> Version: openldap-sasl-server-2.4.23 >>> OS: FreeBSD 8.0-RELEASE-p3 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (89.235.170.154) >>> >>> Hi. When i configure ldap server with overlay proxycache and set >>> pcachePersist=TRUE, only positive answer stay in cache after restart proxy >>> ldap. >>> If not restart proxy ldap, all good, negative answer in cache stay. Why? >>> >>> proxyTemplate (target=) 0 18400 18400 >> Good catch; a fix is in HEAD. Please test it (pcache.c 1.218 -> 1.219) >> and report. Please also note that while tracking this issue I also >> spotted a couple of bugs which have been fixed as ITS#6797 (pcache.c 1.217 >> -> 1.218). >> >> p. >

1 0

Re: (ITS#6796) overlay proxycache
by varnakov-k＠ya.ru 19 Jan '11

19 Jan '11

It works!!! 18.01.2011, 22:47, masarati(a)aero.polimi.it: >> Full_Name: Varnakov Kiril >> Version: openldap-sasl-server-2.4.23 >> OS: FreeBSD 8.0-RELEASE-p3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (89.235.170.154) >> >> Hi. When i configure ldap server with overlay proxycache and set >> pcachePersist=TRUE, only positive answer stay in cache after restart proxy >> ldap. >> If not restart proxy ldap, all good, negative answer in cache stay. Why? >> >> proxyTemplate (target=) 0 18400 18400 > > Good catch; a fix is in HEAD. Please test it (pcache.c 1.218 -> 1.219) > and report. Please also note that while tracking this issue I also > spotted a couple of bugs which have been fixed as ITS#6797 (pcache.c 1.217 > -> 1.218). > > p. -- Best regards

1 0

Re: (ITS#6785) slapo-chain mishandles sr_text/sr_matched
by h.b.furuseth＠usit.uio.no 19 Jan '11

19 Jan '11

masarati(a)aero.polimi.it writes: > What do you suggest? To use a local SlapReply instead of hijacking the > one passed as argument? Not my call, I haven't looked enough at the code to know what it's doing. -- Hallvard

1 0

Re: (ITS#6796) overlay proxycache
by varnakov-k＠ya.ru 19 Jan '11

19 Jan '11

Thank you for fix, soon i test it. 18.01.2011, 22:47, masarati(a)aero.polimi.it: >> Full_Name: Varnakov Kiril >> Version: openldap-sasl-server-2.4.23 >> OS: FreeBSD 8.0-RELEASE-p3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (89.235.170.154) >> >> Hi. When i configure ldap server with overlay proxycache and set >> pcachePersist=TRUE, only positive answer stay in cache after restart proxy >> ldap. >> If not restart proxy ldap, all good, negative answer in cache stay. Why? >> >> proxyTemplate (target=) 0 18400 18400 > > Good catch; a fix is in HEAD. Please test it (pcache.c 1.218 -> 1.219) > and report. Please also note that while tracking this issue I also > spotted a couple of bugs which have been fixed as ITS#6797 (pcache.c 1.217 > -> 1.218). > > p. -- C Õ×ÁÖÅÎÉÅÍ, ÷ÁÒÎÁËÏ× ëÉÒÉÌÌ. ôÅÌÅÆÏÎ: +79153349954 ICQ: 3442880

1 0

Re: (ITS#6788) Only one reference when ldap_open_internal_connection
by hyc＠symas.com 18 Jan '11

18 Jan '11

masarati(a)aero.polimi.it wrote: >> Full_Name: Jiri Giesl >> Version: 2.3.43 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.111.5.220) >> >> >> We tried to estalish connection to LDAP server by our own (because of >> proxy >> usage) and then use "ldap_open_internal_connection" function to initialize >> internal structures of openldap. After successful SASL binding we realized >> that >> the connection to LDAP server has been closed. We found out that there is >> checking for reference count in "wait4msg" function (result.c file) this >> way: >> >> if ( lc->lconn_refcnt<= 1 ) >> >> During classic initialization and SASL binding we get 2 references, >> however when >> using "ldap_open_internal_connection" and SASL binding we get only 1 >> reference. >> >> We realized that in "ldap_open_defconn" (function which is called for >> establishing of a new connection) there is reference counter which is >> increased >> this way: >> >> ++ld->ld_defconn->lconn_refcnt; /* so it never gets closed/freed */ >> >> When we added this incrementation also into >> "ldap_open_internal_connection" >> (open.c file), everything goes well (it is obvious). >> >> Are we wrong or this is really minor bug (missing incrementation of >> reference >> counter in "ldap_open_internal_connection")? > > Your comment sounds fine; however, it's hard to judge: that code is > essentially untouched since 2000 (Mark Adamson) and it is not (or no > longer) used elsewhere in OpenLDAP code. I'd vote for adding a > > ++ld->ld_defconn->lconn_refcnt; > > here as well, unless someone else has valid objections. I'd say they should rewrite their code to use ldap_init_fd() instead; since open_internal_connection does not provide a URL some SASL mechanisms would fail because they don't know the remote hostname. But yeah, probably adding the refcnt is 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#6785) slapo-chain mishandles sr_text/sr_matched
by masarati＠aero.polimi.it 18 Jan '11

18 Jan '11

> Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (193.157.198.89) > Submitted by: hallvard > > > ldap_chain_response() can send sr_text/sr_matched which refers to a > different error than sr_err and rc. > > It saves rs-> sr_err, sr_text, sr_matched to three local variables and > can restore them later, but not maintain the text and matched variables > in parallel with err. Also it does not track/reset/obey > REP_MATCHED_MUSTBEFREED along with sr_matched. > > Fails test032-chain with the asserts below. However there may be > non-success result with the wrong text/matched too, that cannot be > assert()ed. > > Come to think of it, maybe the last issues applies to ITS#6774 too? > REP_MATCHED_MUSTBEFREED, mismatch between failure code and text/matched. > > Index: servers/slapd/back-ldap/chain.c > @@ -1019,4 +1019,14 @@ ldap_chain_response( Operation *op, SlapReply *rs ) > rs->sr_ref = NULL; > > + const char *bad_incoming_matched = NULL, *bad_incoming_text = NULL; > + switch ( sr_err ) { > + case LDAP_SUCCESS: > + case LDAP_COMPARE_TRUE: > + case LDAP_COMPARE_FALSE: > + bad_incoming_matched = matched; > + case LDAP_REFERRAL: > + bad_incoming_text = text; > + } > + > /* we need this to know if back-ldap returned any result */ > lb.lb_lc = lc; > @@ -1169,4 +1179,15 @@ cannot_chain:; > > dont_chain:; > + switch ( sr_err ) { > + case LDAP_SUCCESS: > + case LDAP_COMPARE_TRUE: > + case LDAP_COMPARE_FALSE: > + assert( !matched || bad_incoming_matched ); > + case LDAP_REFERRAL: > + assert( !text || bad_incoming_text ); > + } > + assert( rc != LDAP_SUCCESS || > + (( !text || bad_incoming_text) && > + ( !matched || bad_incoming_matched ))); > rs->sr_err = sr_err; > rs->sr_type = sr_type; What do you suggest? To use a local SlapReply instead of hijacking the one passed as argument? p.

1 0

Re: (ITS#6788) Only one reference when ldap_open_internal_connection
by masarati＠aero.polimi.it 18 Jan '11

18 Jan '11

> Full_Name: Jiri Giesl > Version: 2.3.43 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.111.5.220) > > > We tried to estalish connection to LDAP server by our own (because of > proxy > usage) and then use "ldap_open_internal_connection" function to initialize > internal structures of openldap. After successful SASL binding we realized > that > the connection to LDAP server has been closed. We found out that there is > checking for reference count in "wait4msg" function (result.c file) this > way: > > if ( lc->lconn_refcnt <= 1 ) > > During classic initialization and SASL binding we get 2 references, > however when > using "ldap_open_internal_connection" and SASL binding we get only 1 > reference. > > We realized that in "ldap_open_defconn" (function which is called for > establishing of a new connection) there is reference counter which is > increased > this way: > > ++ld->ld_defconn->lconn_refcnt; /* so it never gets closed/freed */ > > When we added this incrementation also into > "ldap_open_internal_connection" > (open.c file), everything goes well (it is obvious). > > Are we wrong or this is really minor bug (missing incrementation of > reference > counter in "ldap_open_internal_connection")? Your comment sounds fine; however, it's hard to judge: that code is essentially untouched since 2000 (Mark Adamson) and it is not (or no longer) used elsewhere in OpenLDAP code. I'd vote for adding a ++ld->ld_defconn->lconn_refcnt; here as well, unless someone else has valid objections. p.

1 0

Re: (ITS#6739) broken do_syncrep2()
by hyc＠symas.com 18 Jan '11

18 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > slapd/syncrepl.c:do_syncrep2() initializes many variables once which > should have been initialized inside the loop. > > I'll add the initializations I can figure out, and move most variables > into the loop for readability. > > TODO: > > Variables 'm' and 'refreshDeletes' may still be wrong. In particular > 'm'. It "feels" like it should be local to the loop, but there's no > logic that I can see to prevent previous value from being used. > Perhaps they depend on the peer not breaking the sync protocol? > I haven't read that myself, I'm just peering at the code. The refreshPresent/refreshDeletes flags handling is pretty bogus, I agree. It's always been like that and I've never felt like taking the time to clean it up. It Would Be Nice if someone went thru and cleaned up the entire consumer. While the provider was completely rewritten for 2.3, the consumer is still just a series of patches on the original 2.2 code, and it was never good code to begin with. > I've added three somewhat arbitrary bits of code for error handling: > - A Debug() statement on line 847 which can likely be improved. > - Set err and rc to LDAP_OTHER on ldap_parse_result/ldap_get_option > failure. The correct fix would be proper error checks (ITS#6738), > but I don't know what to do on error. > Sounds like LDAP_OTHER is fine; ldap_get_option should never fail and if it does, we have no idea what's going on anyway. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs