- openldap-bugs - openldap.org

Re: (ITS#6741)
by hyc＠symas.com 30 Dec '10

30 Dec '10

jgcardoso(a)seguridata.com wrote: > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01CBA84D.397A800E > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > I submitted a patch for tls2.c in order to handle DER BitString values. LBER_BITSTRING is already defined in lber.h so there's no need to define LBER_TAG_BITSTRING in your patch. I will clean up some of this and then commit 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

(ITS#6741)
by jgcardoso＠seguridata.com 30 Dec '10

30 Dec '10

This is a multi-part message in MIME format. ------_=_NextPart_001_01CBA84D.397A800E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I submitted a patch for tls2.c in order to handle DER BitString values. =20 This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by SeguriData Privada, S.A. de CV. SeguriData Privada S.A de C. V. has not assigned rights and/or interest in this work to any party. I, Juan Gonzalez Cardoso am authorized by SeguriData Privada, S. A. de C. V., my employer, to release this work under the following terms: =20 The attached modifications to OpenLDAP Software are subject to the following notice: =20 Copyright SeguriData Privada, S. A. de C. V. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. =20 Full_Name: Juan Gonzalez Cardoso Version: 2.4.23 OS: Red Hat 5.5 EL URL: ftp://ftp.openldap.org/incoming/juan-gonzalez-101230.patch =20 =20 =20 =20 ------_=_NextPart_001_01CBA84D.397A800E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 = (filtered medium)"><style></style></head><body lang=3DES-MX link=3Dblue = vlink=3Dpurple><div class=3DWordSection1>I submitted a patch for tls2.c in order to handle DER = BitString values.<o:p></o:p><o:p> </o:p> This patch file is derived from OpenLDAP Software. All of = the modifications to OpenLDAP Software represented in the following = patch(es) were developed by SeguriData Privada, S.A. de = CV.<o:p></o:p>SeguriData Privada S.A de C. V. has not assigned rights = and/or interest in this work to any party.<o:p></o:p>I, Juan Gonzalez Cardoso am = authorized by SeguriData Privada, S. A. de C. V., my employer, to = release this work under the following terms:<o:p></o:p><o:p> </o:p>The attached modifications to = OpenLDAP Software are subject to the following = notice:<o:p></o:p><o:p> </o:p>Copyright = SeguriData Privada, S. A. de C. V.<o:p></o:p>Redistribution and use in source = and binary forms, with or without modification, are permitted only as = authorized by the OpenLDAP Public License.<o:p></o:p><o:p> </o:p>Full_Name: Juan Gonzalez = Cardoso<o:p></o:p>Version: 2.4.23<o:p></o:p>OS: Red Hat 5.5 = EL<o:p></o:p>URL: <a = href=3D"ftp://ftp.openldap.org/incoming/juan-gonzalez-101230.patch">ftp:/= /ftp.openldap.org/incoming/juan-gonzalez-101230.patch</a><o:p></o:p></spa= n><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p></div></body></html> ------_=_NextPart_001_01CBA84D.397A800E--

1 0

Re: (ITS#6684)
by hyc＠symas.com 30 Dec '10

30 Dec '10

norbert(a)pueschel.net wrote: > Updated TAR-file with (hopefully) sufficient copyright notice... > > http://www.pueschel.net/openldap/norbert-pueschel-autogroup-27102010.tar Your code does a string compare againset "memberOf" to detect those filter references. 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. Replying to the original: > 1) Using non-DN-valued URIs for autogroup does not work correctly, even > with the latest version from HEAD. Especially changing group member is > not tracked. I don't see why this should ever work or be supported. LDAP groups list DNs. > 2) Using the memberOf-overlay for constructing autogroups does not work I don't see any reason why this should work. The memberof overlay is not used to construct groups, it is only used to report on group memberships that have already been defined. -- -- 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#6664) Server control forwarding in back_meta and back_ldap
by hyc＠symas.com 30 Dec '10

30 Dec '10

masarati(a)aero.polimi.it wrote: >> Note that the SSSVLV overlay can handle paged results locally too, thus >> negating any need for back-ldap/back-meta to forward it to a remote >> server. >> Obviously for greatest generality, there needs to be a way to configure >> which >> set of controls to pass through, and which to process locally. (Much like >> back-ldap's option to process the WhoAmI exop...) > > Right. With proxies the problem is twofold: > > a) clients request pr because they think they're talking to AD > > b) the proxy may need to use pr even if the client does not request it, > because it knows it's talking to AD > > In (a), the issue could be handled the way sssvlv does, relieving the > proxy from having to deal with server-side pr; this would be extremely > beneficial, for example, for back-meta > > In (b), the proxy could be configured to use pr the way I mentioned above; > in principle, the proxy could be so clever to avoid using pr, and simply > accept to handle unrequested pr responses, but only if instructed to do > so. > > Filtering what controls are passed thru should be easy, since both proxy > backends always call ldap_back_controls_add()/meta_back_controls_add() to > muck with request controls (usually to add proxied authorization and so); > this function could easily strip or add pr if instructed to do so. Should also revisit ITS#4591 while thinking about this. -- -- 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#5966
by hyc＠symas.com 30 Dec '10

30 Dec '10

cn=Monitor does not appear to have this problem any more, at least not for test056 or test039 on my dual-core machine. Can we close this out? -- -- 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#5862) Assert control ignored on non-database entries
by hyc＠symas.com 30 Dec '10

30 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > slapd does not apply the Assert control to non-database entries > (at least the root and subschema entries), yet does not reject > a critical control either. > > I have not explored the magnitutde of the problem: Where the > control can get ignored, and which other controls are ignored. > > $ ldapsearch -LLLx -e\!assert='(objectClass=person)' -b "" -s base > dn: > objectClass: top > objectClass: OpenLDAProotDSE > > $ ldapsearch -LLLx -e\!assert='(objectClass=person)' -b cn=subschema -s base > dn: cn=Subschema > objectClass: top > objectClass: subentry > objectClass: subschema > objectClass: extensibleObject > cn: Subschema > > > -b "" -s sub does apply the control with database bdb + suffix "". > Don't know about back-sql. > However I imagine it varies how careful backends "" are about generating > the root DSE when suffix == "" so controls can be applied to it. Might > need a backend flag which says whether the backend does this, and reject > the critical controls with unwillingToPerform if this flag is not set. With ITS#6753 I've centralized Compare processing into the frontend, so the Assert control is now processed for non-database entries with this op. Someone should take a look and see what other operations we need to worry about. -- -- 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#6741)
by hyc＠symas.com 30 Dec '10

30 Dec '10

The ITS doesn't really handle MIME messages very well. Please just follow the guidelines on the OpenLDAP web site. http://www.openldap.org/devel/contributing.html jgcardoso(a)seguridata.com wrote: > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01CBA7B8.A7EC1D62 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > I created a function to support conversion from DER BitString encoded > data to RFC4517 Bit String Format. > > I tested it alone and it seems to work fine with normal and abnormal > situations. > > =20 > > I also wrote a proposal to the call that must be included at > ldap_X509dn2bv() function. > > =20 > > First comes the conversion function and after comes the proposal. > > =20 > > =20 > > /*****************************************************/ > > =20 > > #define BITS_PER_BYTE 8 > > #define SQUOTE_LENGTH 1 > > #define B_CHAR_LENGTH 1 > > #define STR_OVERHEAD (2*SQUOTE_LENGTH + B_CHAR_LENGTH) > > =20 > > int ldap_der_to_rfc4517_BitString (struct berval *berValue, > > struct berval *rfc4517Value) { > > > ber_len_t bitPadding=3D0; > > ber_len_t bits, maxBits; > > char *tmpStr; > > unsigned char byte; > > ber_len_t bitLength; > > ber_len_t valLen; > > unsigned char* valPtr; > > =20 > > rfc4517Value->bv_len=3D0; > > rfc4517Value->bv_val=3DNULL; > > =20 > > /* Gets padding and points to binary data */ > > valLen=3DberValue->bv_len; > > valPtr=3D(unsigned char*)berValue->bv_val; > > if (valLen) { > > bitPadding=3D(ber_len_t)(valPtr[0]); > > valLen--; > > valPtr++; > > } > > /* If Block is non DER encoding fixes to DER encoding */ > > if (bitPadding>=3D BITS_PER_BYTE) { > > if (valLen*BITS_PER_BYTE> bitPadding ) { > > valLen-=3D(bitPadding/BITS_PER_BYTE); > > bitPadding%=3DBITS_PER_BYTE; > > } else { > > valLen=3D0; > > bitPadding=3D0; > > } > > } > > /* Just in case bad encoding */ > > if (valLen*BITS_PER_BYTE< bitPadding ) { > > bitPadding=3D0; > > valLen=3D0; > > } > > =20 > > /* Gets buffer to hold RFC4517 Bit String format */ > > bitLength=3DvalLen*BITS_PER_BYTE-bitPadding; > > tmpStr=3DLDAP_MALLOC(bitLength + STR_OVERHEAD + 1); > > =20 > > if (!tmpStr) > > return LDAP_NO_MEMORY; > > =20 > > rfc4517Value->bv_val=3DtmpStr; > > rfc4517Value->bv_len=3DbitLength + STR_OVERHEAD; > > =20 > > /* Formatting in '*binary-digit'B format */ > > maxBits=3DBITS_PER_BYTE; > > *tmpStr=3D'\''; > > tmpStr++; > > while(valLen) { > > byte=3D*valPtr; > > if (valLen=3D=3D1) > > maxBits-=3DbitPadding; > > for (bits=3D0; bits<maxBits; bits++) { > > if (0x80& byte) > > *tmpStr=3D'1'; > > else > > *tmpStr=3D'0'; > > tmpStr++; > > byte<<=3D1; > > } > > valPtr++; > > valLen--; > > } > > *tmpStr=3D'\''; > > tmpStr++; > > *tmpStr=3D'B'; > > tmpStr++; > > *tmpStr=3D0; > > =20 > > return LDAP_SUCCESS; > > } > > =20 > > =20 > > /*****************************************************/ > > /*****************************************************/ > > =20 > > =20 > > /* > > * Other tags found in AVAs (X.520) > > */ > > #define LBER_TAG_BITSTRING ((ber_tag_t) 0x03UL) > > =20 > > =20 > > ldap_X509dn2bv function updated: > > =20 > > switch(tag) { > > case LBER_TAG_UNIVERSAL: > > /* This uses 32-bit ISO 10646-1 */ > > csize =3D 4; goto to_utf8; > > case LBER_TAG_BMP: > > /* This uses 16-bit ISO 10646-1 */ > > csize =3D 2; goto to_utf8; > > case LBER_TAG_BITSTRING: > > /* X.690 bitString value converted to RFC4517 Bit > String */ > > rc =3D ldap_der_to_rfc4517_BitString(&Val, > &newAVA->la_value ); > > goto after_utf8; > > case LBER_TAG_TELETEX: > > /* This uses 8-bit, assume ISO 8859-1 */ > > csize =3D 1; > > to_utf8: rc =3D ldap_ucs_to_utf8s(&Val, csize, > &newAVA->la_value ); > > after_utf8: newAVA->la_flags |=3D LDAP_AVA_FREE_VALUE; > > if (rc !=3D LDAP_SUCCESS) goto nomem; > > newAVA->la_flags =3D LDAP_AVA_NONPRINTABLE; > > break; > > case LBER_TAG_UTF8: > > newAVA->la_flags =3D LDAP_AVA_NONPRINTABLE; > > /* This is already in UTF-8 encoding */ > > case LBER_TAG_IA5: > > case LBER_TAG_PRINTABLE: > > /* These are always 7-bit strings */ > > newAVA->la_value =3D Val; > > default: > > ; > > } > > =20 > > > ------_=_NextPart_001_01CBA7B8.A7EC1D62 > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = > xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = -- -- 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#6741)
by jgcardoso＠seguridata.com 30 Dec '10

30 Dec '10

This is a multi-part message in MIME format. ------_=_NextPart_001_01CBA7B8.A7EC1D62 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I created a function to support conversion from DER BitString encoded data to RFC4517 Bit String Format. I tested it alone and it seems to work fine with normal and abnormal situations. =20 I also wrote a proposal to the call that must be included at ldap_X509dn2bv() function. =20 First comes the conversion function and after comes the proposal. =20 =20 /*****************************************************/ =20 #define BITS_PER_BYTE 8 #define SQUOTE_LENGTH 1 #define B_CHAR_LENGTH 1 #define STR_OVERHEAD (2*SQUOTE_LENGTH + B_CHAR_LENGTH) =20 int ldap_der_to_rfc4517_BitString (struct berval *berValue, struct berval *rfc4517Value) { ber_len_t bitPadding=3D0; ber_len_t bits, maxBits; char *tmpStr; unsigned char byte; ber_len_t bitLength; ber_len_t valLen; unsigned char* valPtr; =20 rfc4517Value->bv_len=3D0; rfc4517Value->bv_val=3DNULL; =20 /* Gets padding and points to binary data */ valLen=3DberValue->bv_len; valPtr=3D(unsigned char*)berValue->bv_val; if (valLen) { bitPadding=3D(ber_len_t)(valPtr[0]); valLen--; valPtr++; } /* If Block is non DER encoding fixes to DER encoding */ if (bitPadding >=3D BITS_PER_BYTE) { if (valLen*BITS_PER_BYTE > bitPadding ) { valLen-=3D(bitPadding/BITS_PER_BYTE); bitPadding%=3DBITS_PER_BYTE; } else { valLen=3D0; bitPadding=3D0; } } /* Just in case bad encoding */ if (valLen*BITS_PER_BYTE < bitPadding ) { bitPadding=3D0; valLen=3D0; } =20 /* Gets buffer to hold RFC4517 Bit String format */ bitLength=3DvalLen*BITS_PER_BYTE-bitPadding; tmpStr=3DLDAP_MALLOC(bitLength + STR_OVERHEAD + 1); =20 if (!tmpStr) return LDAP_NO_MEMORY; =20 rfc4517Value->bv_val=3DtmpStr; rfc4517Value->bv_len=3DbitLength + STR_OVERHEAD; =20 /* Formatting in '*binary-digit'B format */ maxBits=3DBITS_PER_BYTE; *tmpStr=3D'\''; tmpStr++; while(valLen) { byte=3D*valPtr; if (valLen=3D=3D1) maxBits-=3DbitPadding; for (bits=3D0; bits<maxBits; bits++) { if (0x80 & byte) *tmpStr=3D'1'; else *tmpStr=3D'0'; tmpStr++; byte<<=3D1; } valPtr++; valLen--; } *tmpStr=3D'\''; tmpStr++; *tmpStr=3D'B'; tmpStr++; *tmpStr=3D0; =20 return LDAP_SUCCESS; } =20 =20 /*****************************************************/ /*****************************************************/ =20 =20 /* * Other tags found in AVAs (X.520) */ #define LBER_TAG_BITSTRING ((ber_tag_t) 0x03UL) =20 =20 ldap_X509dn2bv function updated: =20 switch(tag) { case LBER_TAG_UNIVERSAL: /* This uses 32-bit ISO 10646-1 */ csize =3D 4; goto to_utf8; case LBER_TAG_BMP: /* This uses 16-bit ISO 10646-1 */ csize =3D 2; goto to_utf8; case LBER_TAG_BITSTRING: /* X.690 bitString value converted to RFC4517 Bit String */ rc =3D ldap_der_to_rfc4517_BitString( &Val, &newAVA->la_value ); goto after_utf8; case LBER_TAG_TELETEX: /* This uses 8-bit, assume ISO 8859-1 */ csize =3D 1; to_utf8: rc =3D ldap_ucs_to_utf8s( &Val, csize, &newAVA->la_value ); after_utf8: newAVA->la_flags |=3D LDAP_AVA_FREE_VALUE; if (rc !=3D LDAP_SUCCESS) goto nomem; newAVA->la_flags =3D LDAP_AVA_NONPRINTABLE; break; case LBER_TAG_UTF8: newAVA->la_flags =3D LDAP_AVA_NONPRINTABLE; /* This is already in UTF-8 encoding */ case LBER_TAG_IA5: case LBER_TAG_PRINTABLE: /* These are always 7-bit strings */ newAVA->la_value =3D Val; default: ; } =20 ------_=_NextPart_001_01CBA7B8.A7EC1D62 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 = (filtered medium)"><style></style></head><body lang=3DES-MX link=3Dblue = vlink=3Dpurple><div class=3DWordSection1>I created a function to = support conversion from DER BitString encoded data to RFC4517 Bit String = Format.<o:p></o:p>I tested it alone and it seems to = work fine with normal and abnormal situations.<o:p></o:p><o:p> </o:p>I also wrote a proposal = to the call that must be included at ldap_X509dn2bv() = function.<o:p></o:p><o:p> </o:p>First comes the conversion function and after comes the = proposal.<o:p></o:p><o:p> </o:p><o:p> </o:p>/*****************************************************/<o:p></o:p><= /span><o:p> </o:p>#define BITS_PER_BYTE     = 8<o:p></o:p>#define = SQUOTE_LENGTH     1<o:p></o:p>#define B_CHAR_LENGTH     = 1<o:p></o:p>#define = STR_OVERHEAD    (2*SQUOTE_LENGTH + = B_CHAR_LENGTH)<o:p></o:p><o:p> </o:p>int = ldap_der_to_rfc4517_BitString (struct berval = *berValue,<o:p></o:p>         =             &= nbsp;           &n= bsp; struct berval *rfc4517Value) = {            =             &= nbsp;        <o:p></o:p>ber_len_t bitPadding=3D0;<o:p></o:p>ber_len_t bits, maxBits;<o:p></o:p>char *tmpStr;<o:p></o:p>unsigned char = byte;<o:p></o:p>ber_len_t = bitLength;<o:p></o:p>ber_len_t = valLen;<o:p></o:p>unsigned char* = valPtr;<o:p></o:p><o:p> </o:p>   rfc4517Value->bv_len=3D0;<o:p></o:p>   = rfc4517Value->bv_val=3DNULL;<o:p></o:p><o:p> </o:p>   /* Gets = padding and points to binary data */<o:p></o:p>   valLen=3DberValue->bv_len;<o:p></o:p>   valPtr=3D(unsigned = char*)berValue->bv_val;<o:p></o:p>   if (valLen) {<o:p></o:p>      = bitPadding=3D(ber_len_t)(valPtr[0]);<o:p></o:p>      valLen--;<o:p></o:p>      valPtr++;<o:p></o:p>   }<o:p></o:p>   /* If = Block is non DER encoding fixes to DER encoding = */<o:p></o:p>   if (bitPadding >=3D = BITS_PER_BYTE) {<o:p></o:p>      if (valLen*BITS_PER_BYTE > = bitPadding ) {<o:p></o:p>         = valLen-=3D(bitPadding/BITS_PER_BYTE);<o:p></o:p>         = bitPadding%=3DBITS_PER_BYTE;<o:p></o:p>      } else {<o:p></o:p>         = valLen=3D0;<o:p></o:p>         = bitPadding=3D0;<o:p></o:p>      }<o:p></o:p>   }<o:p></o:p>   /* Just in = case bad encoding */<o:p></o:p>   if = (valLen*BITS_PER_BYTE < bitPadding ) {<o:p></o:p>      = bitPadding=3D0;<o:p></o:p>      valLen=3D0;<o:p></o:p>   }<o:p></o:p><o:p> </o:p>   /* Gets = buffer to hold RFC4517 Bit String format */<o:p></o:p>   = bitLength=3DvalLen*BITS_PER_BYTE-bitPadding;<o:p></o:p>   tmpStr=3DLDAP_MALLOC(bitLength + STR_OVERHEAD + = 1);<o:p></o:p>   = <o:p></o:p>   if = (!tmpStr)<o:p></o:p>      = return LDAP_NO_MEMORY;<o:p></o:p><o:p> </o:p>   = rfc4517Value->bv_val=3DtmpStr;<o:p></o:p>   rfc4517Value->bv_len=3DbitLength + = STR_OVERHEAD;<o:p></o:p><o:p> </o:p>   /* = Formatting in '*binary-digit'B format */<o:p></o:p>   maxBits=3DBITS_PER_BYTE;<o:p></o:p>   *tmpStr=3D'\'';<o:p></o:p>   tmpStr++;<o:p></o:p>   while(valLen) {<o:p></o:p>      = byte=3D*valPtr;<o:p></o:p>      if = (valLen=3D=3D1)<o:p></o:p>         = maxBits-=3DbitPadding;<o:p></o:p>      for (bits=3D0; bits<maxBits; = bits++) {<o:p></o:p>         if (0x80 & = byte)<o:p></o:p>            = *tmpStr=3D'1';<o:p></o:p>         = else<o:p></o:p>            = *tmpStr=3D'0';<o:p></o:p>         = tmpStr++;<o:p></o:p>         = byte<<=3D1;<o:p></o:p>      }<o:p></o:p>      valPtr++;<o:p></o:p>      valLen--;<o:p></o:p>   }<o:p></o:p>   = *tmpStr=3D'\'';<o:p></o:p>   = tmpStr++;<o:p></o:p>   = *tmpStr=3D'B';<o:p></o:p>   = tmpStr++;<o:p></o:p>   = *tmpStr=3D0;<o:p></o:p><o:p> </o:p>   return = LDAP_SUCCESS;<o:p></o:p>}<o:p></o:p><o:p> </o:p><o:p> </o:p>/*****************************************************/<o:p></o:p><= /span>/*****************************************************/<o:p></o:p><= /span><o:p> </o:p><o:p> </o:p>/*<o:p></o:p> * Other tags = found in AVAs (X.520)<o:p></o:p> = */<o:p></o:p>#define = LBER_TAG_BITSTRING     ((ber_tag_t) = 0x03UL)<o:p></o:p><o:p> </o:p><o:p> </o:p>ldap_X509dn2bv function = updated:<o:p></o:p><o:p> </o:p>           &= nbsp;    switch(tag) {<o:p></o:p>           &= nbsp;    case LBER_TAG_UNIVERSAL:<o:p></o:p>           &= nbsp;         /* This uses = 32-bit ISO 10646-1 */<o:p></o:p>           &= nbsp;         csize =3D 4; goto = to_utf8;<o:p></o:p>           &= nbsp;    case LBER_TAG_BMP:<o:p></o:p>           &= nbsp;         /* This uses = 16-bit ISO 10646-1 */<o:p></o:p>           &= nbsp;         csize =3D 2; goto = to_utf8;<o:p></o:p>         &nb= sp;      case = LBER_TAG_BITSTRING:<o:p></o:p>         &nb= sp;           /* X.690 = bitString value converted to RFC4517 Bit String = */<o:p></o:p>         &nb= sp;           rc =3D = ldap_der_to_rfc4517_BitString( &Val, &newAVA->la_value = );<o:p></o:p>         &nb= sp;           goto = after_utf8;<o:p></o:p>           &= nbsp;    case LBER_TAG_TELETEX:<o:p></o:p>           &= nbsp;         /* This uses = 8-bit, assume ISO 8859-1 */<o:p></o:p>           &= nbsp;         csize =3D = 1;<o:p></o:p>to_utf8:         &nbsp= ;   rc =3D ldap_ucs_to_utf8s( &Val, csize, = &newAVA->la_value );<o:p></o:p>after_utf8:          = newAVA->la_flags |=3D LDAP_AVA_FREE_VALUE;<o:p></o:p>           &= nbsp;         if (rc !=3D = LDAP_SUCCESS) goto nomem;<o:p></o:p>           &= nbsp;         newAVA->la_flags =3D = LDAP_AVA_NONPRINTABLE;<o:p></o:p>           &= nbsp;         break;<o:p></o:p>           &= nbsp;    case LBER_TAG_UTF8:<o:p></o:p>           &= nbsp;         newAVA->la_flags =3D = LDAP_AVA_NONPRINTABLE;<o:p></o:p>           &= nbsp;         /* This is already in = UTF-8 encoding */<o:p></o:p>           &= nbsp;    case LBER_TAG_IA5:<o:p></o:p>           &= nbsp;    case LBER_TAG_PRINTABLE:<o:p></o:p>           &= nbsp;         /* These are = always 7-bit strings */<o:p></o:p>           &= nbsp;         newAVA->la_value =3D = Val;<o:p></o:p>           &= nbsp;    default:<o:p></o:p>           &= nbsp;         ;<o:p></o:p>           &= nbsp;    }<o:p></o:p><o:p> </o:p></div></body></html> ------_=_NextPart_001_01CBA7B8.A7EC1D62--

1 0

Re: (ITS#6745) HEAD emfile race condition -> slapd stopping listening?
by h.b.furuseth＠usit.uio.no 28 Dec '10

28 Dec '10

Howard Chu wrote: >>h.b.furuseth(a)usit.uio.no wrote: >>> Maybe to compensate, slapd_remove() has code which checks if emfile >>> is too big, but nothing checks if it is too small - which looks like >>> slapd might never start listening again. > > On 2nd thought - I don't see how the outcome you describe can occur. If emfile > is non-zero, the list of listeners will be checked for a listener with > non-zero mute status. If any are found, one is guaranteed to be unmuted. But if emfile becomes too small, it reaches zero with a listener still muted - and with emfile = zero, the nothing is unmuted. -- Hallvard

1 0

Re: (ITS#6745) HEAD emfile race condition -> slapd stopping listening?
by hyc＠symas.com 24 Dec '10

24 Dec '10

Howard Chu wrote: > 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 >> >> >> In HEAD slapd/daemon.c, thanks to HEAD's multiple listener support: >> >> slap_listener() protects emfile with slap_daemon[0 ].sd_mutex, >> but slapd_remove() protects it with slap_daemon[id].sd_mutex. >> >> Maybe to compensate, slapd_remove() has code which checks if emfile >> is too big, but nothing checks if it is too small - which looks like >> slapd might never start listening again. On 2nd thought - I don't see how the outcome you describe can occur. If emfile is non-zero, the list of listeners will be checked for a listener with non-zero mute status. If any are found, one is guaranteed to be unmuted. If none are found, emfile will be zeroed. In no case will slapd fail to unmute a listener. -- -- 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#6745) HEAD emfile race condition -> slapd stopping listening?
by hyc＠symas.com 24 Dec '10

24 Dec '10

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 > > > In HEAD slapd/daemon.c, thanks to HEAD's multiple listener support: > > slap_listener() protects emfile with slap_daemon[0 ].sd_mutex, > but slapd_remove() protects it with slap_daemon[id].sd_mutex. > > Maybe to compensate, slapd_remove() has code which checks if emfile > is too big, but nothing checks if it is too small - which looks like > slapd might never start listening again. > > Simplest fix: add this to slapd_remove(): > > if (id) ldap_pvt_thread_mutex_<lock,unlock>(&slap_daemon[0].sd_mutex ); > > slap_daemon[0].sd_mutex looks quite contended that way, though. > Maybe a separate emfile_mutex is better. Alternatively, just skip the check entirely when id != 0. Which would mean that only closing a session on the first listener would ever trigger the other listeners to be unmuted. Doesn't seem so terrible; if slapd is actually out of descriptors one or two connections either way won't make a huge difference in service. -- -- 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#6449) roadmap update
by hyc＠symas.com 23 Dec '10

23 Dec '10

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: NA > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > http://www.openldap.org/software/roadmap.html needs to be updated to note that > OpenLDAP 2.3 is no longer maintained, same as 2.2 and prior. > Fixed in CVS. Kurt, can you refresh the web site? -- -- 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#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by hyc＠symas.com 23 Dec '10

23 Dec '10

alinachegalati(a)yahoo.com wrote: > Full_Name: Alin Vasile > Version: 2.4.19 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.7) > A patch for this is now in CVS HEAD. > > Hi, > > We have a memory leak LDAP_TIMEOUT is encountered on > ldap_search_ext_invocation and we are unable to determine if it is related to > OpenLdap or not. The following summarizes our code in case the LDAP_TIMEOUT > response is returned : > > LDAPMessage *res ; > > // acquire connection > > // perform search > > if(rc == LDAP_TIMEOUT) > { > ldap_msgfree(res); > // return connection > } > > Is ldap_msgfree(res) enough in this case ? > > We tested our program by enabling a low timeout and hence all ldap calls > resulting in timeout. The memory leak is about 9 Megs in several minutes, at a > load of 5 req/ sec. > > dmalloc sees the following not allocated pointers > > 6642692 bytes : Line 640 of "io.c" starts at address 0xff2659c4 > <ber_get_next+468> and ends at 0xff2659cc<ber_get_next+476>. > > 2019876 bytes : Line 277 of "memory.c" starts at address 0xff26676c > <ber_memcalloc_x+132> and ends at 0xff266774<ber_memcalloc_x+140>. > > > -- -- 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#6680) slapd why sasl error message?
by Howard Chu 23 Dec '10

23 Dec '10

>From your log info, your client is obviously using SASL DIGEST-MD5. There is nothing relevant to slapd or the OpenLDAP code here, fix your client if you want these errors to stop. Closing this ITS.

1 0

Fwd: (ITS#6750) About 3rd Party Technical Support Services
by kurt＠OpenLDAP.org 23 Dec '10

23 Dec '10

--Apple-Mail-80--876671303 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: "harrybetter" <harrybetter(a)qq.com> > Date: December 22, 2010 10:32:22 PM PST > To: "Kurt Zeilenga" <kurt(a)openldap.org> > Subject: Re: (ITS#6750) About 3rd Party Technical Support Services > x-spam-status: No, score=3D-0.5 required=3D5.0 = tests=3DBAYES_00,DKIM_SIGNED, = FILL_THIS_FORM_FRAUD_PHISH,FREEMAIL_FROM,FROM_EXCESS_BASE64,HTML_MESSAGE, = RCVD_IN_DNSWL_NONE,T_DKIM_INVALID,T_FILL_THIS_FORM_SHORT,T_RP_MATCHES_RCVD= autolearn=3Dno version=3D3.3.1 >=20 > =20 > anwser is below. >=20 > Please provide the URL for your website/webpage to which your listing = should be linked to? > answer : www.seojindsa.kr >=20 > Please provide a URL to a webpage at your website which details = technical support services=20 > which are specifically tailored to users of OpenLDAP Software? (may be = same as the above URL) > answer : www.seojindsa.kr >=20 > Please provide a summary of your current participation in the OpenLDAP = community? > anwser : Provides consultancy, development, training and user support = for OpenLDAP Software in korea, china. > we will convert openldap document by korean, chinese. >=20 > Please provide an email address (possibly yours) at a domain = registered to SeojinDSA we can use to confirm your association with = SeojinDSA?=20 > answer : sjsong(a)seojindsa.kr=20 >=20 > =20 > =20 > ------------------ Original ------------------ > From: "Kurt Zeilenga"<kurt(a)OpenLDAP.org>; > Date: Thu, Dec 16, 2010 11:36 AM > To: "harrybetter"<harrybetter(a)qq.com>; > Cc: "openldap-its"<openldap-its(a)openldap.org>; > Subject: Re: (ITS#6750) About 3rd Party Technical Support Services > =20 >=20 > On Dec 15, 2010, at 5:27 PM, harrybetter(a)qq.com wrote: >=20 > > Full_Name: Jerry Liu > > Version: openldap-2.4.23 > > OS: RedHatLinux EL5 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (221.0.151.187) > >=20 > >=20 > > We are SeojinDSA CO,LTD. We sincerely hope to show our company = name and link > > on list of "Technical Support" page. But we do not know how to = apply, I hope > > this reply. >=20 > By filing an ITS with your request, you have applied. >=20 > > SeojinDSA is an emerging leader in the Korean field of = next-generation > > Directory Service(LDAP) and Identity Managerment(IAM:Identity Access > > Management????The company's headquarter is in Seoul.Our Company is = made up of > > experts and thought leaders who are recognized for building = world-class > > Directory Service. >=20 > A couple of questions. >=20 > Please provide the URL for your website/webpage to which your listing = should be linked to? > Please provide a URL to a webpage at your website which details = technical support services which are specifically tailored to users of = OpenLDAP Software? (may be same as the above URL) > Please provide a summary of your current participation in the OpenLDAP = community? > Please provide an email address (possibly yours) at a domain = registered to SeojinDSA we can use to confirm your association with = SeojinDSA? If you do not wish this email to be made public (all = openldap-its(a)openldap.org is public), you may send this email address = directly to me at <kurt(a)openldap.org>. >=20 > (It's okay for the above requested URLs to refer to non-English web = pages.) >=20 > Regards, Kurt --Apple-Mail-80--876671303 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "> <div> <div>Begin forwarded message:</div> <blockquote type=3D"cite"><div = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;">From: "harrybetter" = <<a = href=3D"mailto:harrybetter@qq.com">harrybetter(a)qq.com</a>> </= div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: = 0px; margin-left: 0px;">Date: December 22, 2010 = 10:32:22 PM PST </div><div style=3D"margin-top: 0px; = margin-right: 0px; margin-bottom: 0px; margin-left: 0px;">To: "Kurt Zeilenga" <<a = href=3D"mailto:kurt@openldap.org">kurt(a)openldap.org</a>> </di= v><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;">Subject: Re: (ITS#6750) = About 3rd Party Technical Support Services </div><div = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;">x-spam-status: = No, score=3D-0.5 required=3D5.0 = tests=3DBAYES_00,DKIM_SIGNED, = FILL_THIS_FORM_FRAUD_PHISH,FREEMAIL_FROM,FROM_EXCESS_BASE64,HTML_MESSAGE, = RCVD_IN_DNSWL_NONE,T_DKIM_INVALID,T_FILL_THIS_FORM_SHORT,T_RP_MATCHES_RCVD= autolearn=3Dno = version=3D3.3.1 </div> <div><includetail> </includetail>= </div> <div> <div style=3D"COLOR: #000"> <div>anwser is = below.Please = provide the URL for your website/webpage to which your listing should be = linked to? answer : <a href=3D"http://www.seojindsa.kr/" = target=3D"_blank">www.seojindsa.kr</a>Please provide a URL to a webpage at your = website which details technical support services which are = specifically tailored to users of OpenLDAP Software? (may be same as the = above URL) answer : <a href=3D"http://www.seojindsa.kr/" = target=3D"_blank">www.seojindsa.kr</a>Please provide a summary of your current = participation in the OpenLDAP community? anwser : Provides = consultancy, development, training and user support for OpenLDAP = Software in korea, china.          = we will convert openldap document by korean, chinese.Please provide an email = address (possibly yours) at a domain registered to SeojinDSA we can use = to confirm your association with SeojinDSA? answer : <a = href=3D"mailto:sjsong@seojindsa.kr" target=3D"_blank">sjsong(a)seojindsa.kr</a> </div> <div> <div> </div> <div> </div> <div style=3D"COLOR: #000"> <div style=3D"PADDING-BOTTOM: 2px; PADDING-LEFT: 0px; PADDING-RIGHT: = 0px; FONT-FAMILY: Arial Narrow; FONT-SIZE: 12px; PADDING-TOP: = 2px">------------------ Original ------------------</div> <div style=3D"PADDING-BOTTOM: 8px; PADDING-LEFT: 8px; PADDING-RIGHT: = 8px; BACKGROUND: #efefef; FONT-SIZE: 12px; PADDING-TOP: 8px"> <div id=3D"menu_sender">From:  "Kurt Zeilenga"<<a = href=3D"mailto:kurt@OpenLDAP.org">kurt(a)OpenLDAP.org</a>>;</div> <div>Date:  Thu, Dec 16, 2010 11:36 AM</div> <div>To:  "harrybetter"<<a = href=3D"mailto:harrybetter@qq.com">harrybetter(a)qq.com</a>>; = </div> <div>Cc:  "openldap-its"<<a = href=3D"mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>&gt= ;; </div> <div>Subject:  Re: (ITS#6750) About 3rd Party Technical = Support Services</div></div> <div> </div> On Dec 15, 2010, at 5:27 PM, <a = href=3D"mailto:harrybetter@qq.com">harrybetter(a)qq.com</a> = wrote: > Full_Name: Jerry Liu > Version: = openldap-2.4.23 > OS: RedHatLinux EL5 > URL: <a = href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/= </a> > Submission from: (NULL) (221.0.151.187) > > = >    We are SeojinDSA CO,LTD. We sincerely hope to show = our company name and link > on list of "Technical Support" page. = But we do not know how to apply, I hope > this reply. By = filing an ITS with your request, you have applied. >  =   SeojinDSA is an emerging leader in the Korean field of = next-generation > Directory Service(LDAP) and Identity = Managerment(IAM:Identity Access > Management????The company's = headquarter is in Seoul.Our Company is made up of > experts and = thought leaders who are recognized for building world-class > = Directory Service. A couple of questions. Please provide = the URL for your website/webpage to which your listing should be linked = to? Please provide a URL to a webpage at your website which details = technical support services which are specifically tailored to users of = OpenLDAP Software? (may be same as the above URL) Please provide a = summary of your current participation in the OpenLDAP = community? Please provide an email address (possibly yours) at a = domain registered to SeojinDSA we can use to confirm your association = with SeojinDSA?  If you do not wish this email to be made public = (all <a = href=3D"mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a> = is public), you may send this email address directly to me at <<a = href=3D"mailto:kurt@openldap.org">kurt(a)openldap.org</a>>. (It's = okay for the above requested URLs to refer to non-English web = pages.) Regards, = Kurt</div></div></div></div></blockquote></div> </body></html>= --Apple-Mail-80--876671303--

1 0

Re: (ITS#6478) slapd crashes with segfault
by hyc＠symas.com 20 Dec '10

20 Dec '10

wolfgang.hummel(a)hp.com wrote: > We had some of this crashes on LDAP slaves in the past: This appears to be due to your custom template overlay. You probably need to check its correctness using a tool like valgrind or Purify. > In /var/log/messages > 2010-12-05T11:22:57.643777+01:00 ts2mstsv001 kernel: 6>slapd[18900000000000= > 0025 rip 0000003be707p 000000 > > Stack trace when crash occurred (search for entry 0xe932208 in back db (BD= > B) response is contained a corrupted address) > #0 0x0000003be7075b50 in strcpy () from /lib64/libc.so.6 > #1 0x00002b5ffe3debeb in template_response (op=3D0xfa01aa0, rs=3D0x4813bc6= > 0) at /usr/include/bits/string3.h:118 > #2 0x00000000004a34eb in over_back_response (op=3D0xfa01aa0, rs=3D0x4813bc= > 60) at ../servers/slapd/backover.c:237 > #3 0x0000000000449865 in slap_response_play (op=3D0xfa01aa0, rs=3D0x4813bc= > 60) at ../servers/slapd/result.c:402 > #4 0x000000000044bfcc in slap_send_search_entry (op=3D0xfa01aa0, rs=3D0x48= > 13bc60) at ../servers/slapd/result.c:887 > #5 0x00000000004b695f in bdb_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at s= > ervers/slapd/back-bdb/search.c:961 > #6 0x00000000004a37c2 in overlay_op_walk (op=3D0xfa01aa0, rs=3D0x4813bc60,= > which=3Dop_search, oi=3D0xe5df160, on=3D0x0) at ../servers/slapd/backover.= > c:669 > #7 0x00000000004a3d58 in over_op_func (op=3D0xfa01aa0, rs=3D0x4813bc60, wh= > ich=3Dop_search) at ../servers/slapd/backover.c:721 > #8 0x000000000043c4e6 in fe_op_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at= > ../servers/slapd/search.c:376 > #9 0x00000000004a37c2 in overlay_op_walk (op=3D0xfa01aa0, rs=3D0x4813bc60,= > which=3Dop_search, oi=3D0xe577ec0, on=3D0x0) at ../servers/slapd/backover.= > c:669 > #10 0x00000000004a3d58 in over_op_func (op=3D0xfa01aa0, rs=3D0x4813bc60, wh= > ich=3Dop_search) at ../servers/slapd/backover.c:721 > #11 0x000000000043cc95 in do_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at ..= > /servers/slapd/search.c:227 > #12 0x0000000000439ff4 in connection_operation (ctx=3D0x4813bdb0, arg_v=3D<= > value optimized out>) at ../servers/slapd/connection.c:1109 > #13 0x000000000043a651 in connection_read_thread (ctx=3D0x4813bdb0, argv=3D= > <value optimized out>) at ../servers/slapd/connection.c:1245 > #14 0x00000000005330a8 in ldap_int_thread_pool_wrapper (xpool=3D0xe546600) = > at ../libraries/libldap_r/tpool.c:685 > #15 0x0000003be7c062e7 in start_thread () from /lib64/libpthread.so.0 > #16 0x0000003be70ce3bd in clone () from /lib64/libc.so.6 > > (gdb) fr 11 > #11 0x000000000043cc95 in do_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at ..= > /servers/slapd/search.c:227 > 227 ../servers/slapd/search.c: No such file or directory. > in ../servers/slapd/search.c > (gdb) p * op > $55 =3D {o_hdr =3D 0xfa01c10, o_tag =3D 99, o_time =3D 1291544577, o_tincr = > =3D 140, o_bd =3D 0x47fb9ea0, o_req_dn =3D {bv_len =3D 41, bv_val =3D 0x102= > 51e00 "ou=3Dcms,ou=3Dprofiles,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, > o_req_ndn =3D {bv_len =3D 41, bv_val =3D 0x10251ee0 "ou=3Dcms,ou=3Dprofil= > es,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, o_request =3D {oq_add =3D {rs_modlist = > =3D 0x2, rs_e =3D 0x500000064}, oq_bind =3D {rb_method =3D 2, > rb_cred =3D {bv_len =3D 21474836580, bv_val =3D 0x0}, rb_edn =3D {bv_= > len =3D 0, bv_val =3D 0x10251fc0 "\020"}, rb_ssf =3D 270868336, rb_mech =3D= > {bv_len =3D 18, > bv_val =3D 0x10251f98 "(uid=3D491710471677)"}}, oq_compare =3D {rs_= > ava =3D 0x2}, oq_modify =3D {rs_mods =3D {rs_modlist =3D 0x2, rs_no_opattrs= > =3D 100 'd'}, rs_increment =3D 0}, oq_modrdn =3D { > rs_mods =3D {rs_modlist =3D 0x2, rs_no_opattrs =3D 100 'd'}, rs_delet= > eoldrdn =3D 0, rs_newrdn =3D {bv_len =3D 0, bv_val =3D 0x10251fc0 "\020"}, = > rs_nnewrdn =3D {bv_len =3D 270868336, > bv_val =3D 0x12<Address 0x12 out of bounds>}, rs_newSup =3D 0x1025= > 1f98, rs_nnewSup =3D 0x0}, oq_search =3D {rs_scope =3D 2, rs_deref =3D 0, r= > s_slimit =3D 100, rs_tlimit =3D 5, > rs_limit =3D 0x0, rs_attrsonly =3D 0, rs_attrs =3D 0x10251fc0, rs_fil= > ter =3D 0x10251f70, rs_filterstr =3D {bv_len =3D 18, bv_val =3D 0x10251f98 = > "(uid=3D491710471677)"}}, oq_abandon =3D { > rs_msgid =3D 2}, oq_cancel =3D {rs_msgid =3D 2}, oq_extended =3D {rs_= > reqoid =3D {bv_len =3D 2, bv_val =3D 0x500000064<Address 0x500000064 out o= > f bounds>}, rs_flags =3D 0, rs_reqdata =3D 0x0}, > oq_pwdexop =3D {rs_extended =3D {rs_reqoid =3D {bv_len =3D 2, bv_val = > =3D 0x500000064<Address 0x500000064 out of bounds>}, rs_flags =3D 0, rs_re= > qdata =3D 0x0}, rs_old =3D {bv_len =3D 270868416, > bv_val =3D 0x10251f70 "=A3"}, rs_new =3D {bv_len =3D 18, bv_val =3D= > 0x10251f98 "(uid=3D491710471677)"}, rs_mods =3D 0x0, rs_modtail =3D 0x0}},= > o_abandon =3D 0, o_cancel =3D 0, o_groups =3D 0x0, > o_do_not_cache =3D 0 '\0', o_is_auth_check =3D 0 '\0', o_dont_replicate = > =3D 0 '\0', o_acl_priv =3D ACL_NONE, o_nocaching =3D 0 '\0', o_delete_glue_= > parent =3D 0 '\0', o_no_schema_check =3D 0 '\0', > o_no_subordinate_glue =3D 0 '\0', o_ctrlflag =3D '\0'<repeats 31 times>,= > o_controls =3D 0xfa01d58, o_authz =3D {sai_method =3D 128, sai_mech =3D {b= > v_len =3D 0, bv_val =3D 0x0}, sai_dn =3D { > bv_len =3D 51, bv_val =3D 0x2aaab89f0a50 "uid=3Dadmin,ou=3Dcms,ou=3Dp= > rofiles,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, sai_ndn =3D {bv_len =3D 51, > bv_val =3D 0x2aaab8a04e20 "uid=3Dadmin,ou=3Dcms,ou=3Dprofiles,ou=3Dmm= > o,c=3Dde,o=3Dvodafone"}, sai_ssf =3D 0, sai_transport_ssf =3D 0, sai_tls_ss= > f =3D 0, sai_sasl_ssf =3D 0}, o_ber =3D 0x2aaac8098630, > o_res_ber =3D 0x0, o_callback =3D 0x4813a740, o_ctrls =3D 0x0, o_csn =3D = > {bv_len =3D 0, bv_val =3D 0x0}, o_private =3D 0x0, o_extra =3D {slh_first = > =3D 0x4813a480}, o_next =3D {stqe_next =3D 0x0}} > (gdb) p * rs > $56 =3D {sr_type =3D REP_SEARCH, sr_tag =3D 0, sr_msgid =3D 0, sr_err =3D 0= > , sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr= > _un =3D {sru_search =3D {r_entry =3D 0xe932208, > r_attr_flags =3D 17, r_operational_attrs =3D 0x0, r_attrs =3D 0x10251= > fc0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0xe93= > 2208}, sru_extended =3D { > r_rspoid =3D 0xe932208 "\2002\a", r_rspdata =3D 0x11}}, sr_flags =3D = > 4} > > Frame analysis (function called) > (gdb) fr 0 > #0 0x0000003be7075b50 in strcpy () from /lib64/libc.so.6 > (gdb) info registers > rax 0x1 1 > rbx 0x1 1 > rcx 0x3 3 > rdx 0x47f37648 1207137864 > rsi 0x25 37 > rdi 0x47f37648 1207137864 > rbp 0x47f265e4 0x47f265e4 > rsp 0x47a25518 0x47a25518 > r8 0xfefefefefefefeff -72340172838076673 > r9 0x4813bdd0 1209253328 > r10 0x2aaab8000020 46912719814688 > r11 0x206 518 > r12 0xe5e2ae0 241052384 > r13 0x0 0 > r14 0xfa01aa0 262150816 > r15 0x6 6 > rip 0x3be7075b50 0x3be7075b50<strcpy+16> > eflags 0x10217 [ CF PF AF IF RF ] > cs 0x33 51 > ss 0x2b 43 > ds 0x0 0 > es 0x0 0 > fs 0x63 99 > gs 0x0 0 > (gdb) disas=20 > Dump of assembler code for function strcpy: > 0x0000003be7075b40<strcpy+0>: mov %rsi,%rcx > 0x0000003be7075b43<strcpy+3>: and $0x7,%ecx > 0x0000003be7075b46<strcpy+6>: mov %rdi,%rdx > 0x0000003be7075b49<strcpy+9>: je 0x3be7075b66<strcpy+38> > 0x0000003be7075b4b<strcpy+11>: neg %ecx > 0x0000003be7075b4d<strcpy+13>: add $0x8,%ecx > 0x0000003be7075b50<strcpy+16>: mov (%rsi),%al > > rsi is a parameter of strcpy.=20 > rsi should be an address but we have 0x25 which is an invalid address. So c= > rash 2010-12-05T11:22:57.643777+01:00 ts2mstsv001 kernel: 6>slapd[189000000= > 000000025 rip 0000003be707p 000000 > rsi is not modified in strcpy, then, check rsi calculation in template_resp= > onse > > (gdb) fr 1 > #1 0x00002b5ffe3debeb in template_response (op=3D0xfa01aa0, rs=3D0x4813bc6= > 0) at /usr/include/bits/string3.h:118 > 118 return __builtin___strcpy_chk (__dest, __src, __bos (__dest)); > (gdb) info registers > rax 0x1 1 > rbx 0x1 1 > rcx 0x3 3 > rdx 0x47f37648 1207137864 > rsi 0x25 37 > rdi 0x47f37648 1207137864 > rbp 0x47f265e4 0x47f265e4 > rsp 0x47a25520 0x47a25520 > r8 0xfefefefefefefeff -72340172838076673 > r9 0x4813bdd0 1209253328 > r10 0x2aaab8000020 46912719814688 > r11 0x206 518 > r12 0xe5e2ae0 241052384 > r13 0x0 0 > r14 0xfa01aa0 262150816 > r15 0x6 6 > rip 0x2b5ffe3debeb 0x2b5ffe3debeb<template_response+3787> > eflags 0x10217 [ CF PF AF IF RF ] > cs 0x33 51 > ss 0x2b 43 > ds 0x0 0 > es 0x0 0 > fs 0x63 99 > gs 0x0 0 > > (gdb) disass 0x00002b5ffe3debeb > Dump of assembler code for function template_response: > ... > 0x00002b5ffe3deb86<template_response+3686>: lea 0x5010c4(%rsp),%rbp > 0x00002b5ffe3deb8e<template_response+3694>: xor %r15d,%r15d > 0x00002b5ffe3deb91<template_response+3697>: xor %r13d,%r13d > 0x00002b5ffe3deb94<template_response+3700>: mov %rdx,0x30(%rsp) > 0x00002b5ffe3deb99<template_response+3705>: mov %rcx,0x28(%rsp) > 0x00002b5ffe3deb9e<template_response+3710>: jmp 0x2b5ffe3dec07<temp= > late_response+3815> > 0x00002b5ffe3deba0<template_response+3712>: mov 0x511900(%rsp),%rax > 0x00002b5ffe3deba8<template_response+3720>: test %rax,%rax > 0x00002b5ffe3debab<template_response+3723>: je 0x2b5ffe3debeb<temp= > late_response+3787> > 0x00002b5ffe3debad<template_response+3725>: mov 0x8(%rax),%rsi > 0x00002b5ffe3debb1<template_response+3729>: test %rsi,%rsi > 0x00002b5ffe3debb4<template_response+3732>: je 0x2b5ffe3debeb<temp= > late_response+3787> > 0x00002b5ffe3debb6<template_response+3734>: cmpq $0x7ff,(%rax) > 0x00002b5ffe3debbd<template_response+3741>: ja 0x2b5ffe3df966<temp= > late_response+7238> > 0x00002b5ffe3debc3<template_response+3747>: movslq 0x512124(%rsp),%rdi > 0x00002b5ffe3debcb<template_response+3755>: mov 0x28(%rsp),%rdx > 0x00002b5ffe3debd0<template_response+3760>: lea 0x1(%rdi),%eax > 0x00002b5ffe3debd3<template_response+3763>: shl $0xb,%rdi > 0x00002b5ffe3debd7<template_response+3767>: lea 0x808(%rdi,%rdx,1),%= > rdi > 0x00002b5ffe3debdf<template_response+3775>: mov %eax,0x512124(%rsp) > 0x00002b5ffe3debe6<template_response+3782>: callq 0x2b5ffe3dc688<strc= > py@plt> > 0x00002b5ffe3debeb<template_response+3787>: lea 0x1(%r13),%eax > (gdb) p *(long **)($rsp+0x511900) > $17 =3D (long *) 0x2aaab4859d00 > (gdb) x/20x 0x2aaab4859d00 > 0x2aaab4859d00: 0x00000000 0x00000000 0x00000025 0x00000000 > > rsi is broken, not a valid address. > > > Wolfgang Hummel > > > -- -- 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#6747) LDAP_CONNECTIONLESS nitpicks
by Kurt＠OpenLDAP.org 20 Dec '10

20 Dec '10

On Dec 20, 2010, at 2:51 AM, Hallvard B Furuseth wrote: > Kurt(a)OpenLDAP.org writes: >> My nitpick regarding this feature is that it still exists. :-) >=20 > Actually there still are complaints that OpenLDAP has lost cldap - = from > people trying to get Windows/Samba to cooperate with OpenLDAP. That's MSCLDAP not CLDAP. Just another nitpick. > Windows > apparently sends a cldap message as an "LDAP ping". > http://ubuntuforums.org/showthread.php?t=3D673292 > http://onemansjourneyintolinux.blogspot.com/2008/06/cldap.html >=20 > Personally I only compiled it since it exists - I randomize my config > options a bit now and then for testing. I suggest that those that care about MSCLDAP or CLDAP, submit patches to = correct any issues they with its implementation. Continuing bitrot, to = me, is an indication that the code should be removed. -- Kurt=

1 0

Re: (ITS#6747) LDAP_CONNECTIONLESS nitpicks
by h.b.furuseth＠usit.uio.no 20 Dec '10

20 Dec '10

Kurt(a)OpenLDAP.org writes: > My nitpick regarding this feature is that it still exists. :-) Actually there still are complaints that OpenLDAP has lost cldap - from people trying to get Windows/Samba to cooperate with OpenLDAP. Windows apparently sends a cldap message as an "LDAP ping". http://ubuntuforums.org/showthread.php?t=673292 http://onemansjourneyintolinux.blogspot.com/2008/06/cldap.html Personally I only compiled it since it exists - I randomize my config options a bit now and then for testing. -- Hallvard

1 0

(ITS#6753) Compare operation broken with attribute inheritance
by h.b.furuseth＠usit.uio.no 20 Dec '10

20 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (193.157.200.213) Submitted by: hallvard back-bdb, back-monitor: If attr A is ACL-protected and inherits from B, one can still check its value with ldapcompare ... 'B:value'. back-config: Compare doesn't seem to support attribute inheritance. root DSE, cn=subschema: Inheritance works correctly. ######## acl.conf include servers/slapd/schema/core.schema rootdse root.ldif access to attrs=st,cn by * none access to * by * read database bdb suffix o=foo directory acl.dir dbconfig set_flags DB_LOG_AUTOREMOVE database monitor database config access to * by * read ######## root.ldif dn: objectClass: extensibleObject st: hidden ######## slapadd: acl.ldif dn: o=foo objectClass: organization st: hidden ######## Results. cn=config should get TRUE, others UNDEFINED. ldapcompare -x cn=config name:config -> UNDEFINED, No such attribute (16) ldapcompare -x cn=config cn:config -> TRUE ldapcompare -x o=foo name:hidden -> TRUE ldapcompare -x o=foo st:hidden -> UNDEFINED, Insufficient access (50) ldapcompare -x cn=monitor name:monitor -> TRUE ldapcompare -x cn=monitor cn:monitor -> UNDEFINED, Insufficient access (50) ldapcompare -x '' name:hidden -> UNDEFINED, Insufficient access (50) ldapcompare -x '' cn:hidden -> UNDEFINED, Insufficient access (50) ldapcompare -x cn=subschema cn:subschema ->UNDEFINED,Insufficient access (50) ldapcompare -x cn=subschema name:subschema ->UNDEFINED,Insufficient access (50)

1 0

(ITS#6752) slapo-dynlist issues
by h.b.furuseth＠usit.uio.no 20 Dec '10

20 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: Submission from: (NULL) (193.157.200.213) Submitted by: hallvard Dynlist Compare operation: - dynlist_compare() can use an entry after it has been released. It thinks that clearing rs->sr_entry prevents a search from releasing the entry, even after the search completes. Not so. Dynlist mostly worked anyway, I think because dynlist itself follows this expectation for entries without REP_ENTRY_MODIFIABLE which it has duplicated. That includes entries it receives directly from back-bdb. - dynlist_compare() can do needless work: search the same entry several times, fetch an entry to search in a backend which does not support searching, find authz for an entry which will not be searched. - dynlist_sc_save_entry() could read rs->sr_entry when rs->sr_type != REP_SEARCH, which means some other part of the union may be in use. Search operation: - dynlist_sc_update() did not clear REP_ENTRY_MODIFIABLE when freeing. - dynlist_prepare_entry() did not honor REP_ENTRY_MUSTRELEASE. OpenLDAP 2.2/2.3 compatibility code: - Can be dropped, recent dynlist.c does not compile on these versions. Fixing. Simplest Compare fix will ignore errors from o.o_bd->be_search(), just like dynlist_prepare_entry() does.

1 0

Re: (ITS#6478) slapd crashes with segfault
by wolfgang.hummel＠hp.com 19 Dec '10

19 Dec '10

We had some of this crashes on LDAP slaves in the past: In /var/log/messages 2010-12-05T11:22:57.643777+01:00 ts2mstsv001 kernel: 6>slapd[18900000000000= 0025 rip 0000003be707p 000000 Stack trace when crash occurred (search for entry 0xe932208 in back db (BD= B) response is contained a corrupted address) #0 0x0000003be7075b50 in strcpy () from /lib64/libc.so.6 #1 0x00002b5ffe3debeb in template_response (op=3D0xfa01aa0, rs=3D0x4813bc6= 0) at /usr/include/bits/string3.h:118 #2 0x00000000004a34eb in over_back_response (op=3D0xfa01aa0, rs=3D0x4813bc= 60) at ../servers/slapd/backover.c:237 #3 0x0000000000449865 in slap_response_play (op=3D0xfa01aa0, rs=3D0x4813bc= 60) at ../servers/slapd/result.c:402 #4 0x000000000044bfcc in slap_send_search_entry (op=3D0xfa01aa0, rs=3D0x48= 13bc60) at ../servers/slapd/result.c:887 #5 0x00000000004b695f in bdb_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at s= ervers/slapd/back-bdb/search.c:961 #6 0x00000000004a37c2 in overlay_op_walk (op=3D0xfa01aa0, rs=3D0x4813bc60,= which=3Dop_search, oi=3D0xe5df160, on=3D0x0) at ../servers/slapd/backover.= c:669 #7 0x00000000004a3d58 in over_op_func (op=3D0xfa01aa0, rs=3D0x4813bc60, wh= ich=3Dop_search) at ../servers/slapd/backover.c:721 #8 0x000000000043c4e6 in fe_op_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at= ../servers/slapd/search.c:376 #9 0x00000000004a37c2 in overlay_op_walk (op=3D0xfa01aa0, rs=3D0x4813bc60,= which=3Dop_search, oi=3D0xe577ec0, on=3D0x0) at ../servers/slapd/backover.= c:669 #10 0x00000000004a3d58 in over_op_func (op=3D0xfa01aa0, rs=3D0x4813bc60, wh= ich=3Dop_search) at ../servers/slapd/backover.c:721 #11 0x000000000043cc95 in do_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at ..= /servers/slapd/search.c:227 #12 0x0000000000439ff4 in connection_operation (ctx=3D0x4813bdb0, arg_v=3D<= value optimized out>) at ../servers/slapd/connection.c:1109 #13 0x000000000043a651 in connection_read_thread (ctx=3D0x4813bdb0, argv=3D= <value optimized out>) at ../servers/slapd/connection.c:1245 #14 0x00000000005330a8 in ldap_int_thread_pool_wrapper (xpool=3D0xe546600) = at ../libraries/libldap_r/tpool.c:685 #15 0x0000003be7c062e7 in start_thread () from /lib64/libpthread.so.0 #16 0x0000003be70ce3bd in clone () from /lib64/libc.so.6 (gdb) fr 11 #11 0x000000000043cc95 in do_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at ..= /servers/slapd/search.c:227 227 ../servers/slapd/search.c: No such file or directory. in ../servers/slapd/search.c (gdb) p * op $55 =3D {o_hdr =3D 0xfa01c10, o_tag =3D 99, o_time =3D 1291544577, o_tincr = =3D 140, o_bd =3D 0x47fb9ea0, o_req_dn =3D {bv_len =3D 41, bv_val =3D 0x102= 51e00 "ou=3Dcms,ou=3Dprofiles,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, o_req_ndn =3D {bv_len =3D 41, bv_val =3D 0x10251ee0 "ou=3Dcms,ou=3Dprofil= es,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, o_request =3D {oq_add =3D {rs_modlist = =3D 0x2, rs_e =3D 0x500000064}, oq_bind =3D {rb_method =3D 2, rb_cred =3D {bv_len =3D 21474836580, bv_val =3D 0x0}, rb_edn =3D {bv_= len =3D 0, bv_val =3D 0x10251fc0 "\020"}, rb_ssf =3D 270868336, rb_mech =3D= {bv_len =3D 18, bv_val =3D 0x10251f98 "(uid=3D491710471677)"}}, oq_compare =3D {rs_= ava =3D 0x2}, oq_modify =3D {rs_mods =3D {rs_modlist =3D 0x2, rs_no_opattrs= =3D 100 'd'}, rs_increment =3D 0}, oq_modrdn =3D { rs_mods =3D {rs_modlist =3D 0x2, rs_no_opattrs =3D 100 'd'}, rs_delet= eoldrdn =3D 0, rs_newrdn =3D {bv_len =3D 0, bv_val =3D 0x10251fc0 "\020"}, = rs_nnewrdn =3D {bv_len =3D 270868336, bv_val =3D 0x12 <Address 0x12 out of bounds>}, rs_newSup =3D 0x1025= 1f98, rs_nnewSup =3D 0x0}, oq_search =3D {rs_scope =3D 2, rs_deref =3D 0, r= s_slimit =3D 100, rs_tlimit =3D 5, rs_limit =3D 0x0, rs_attrsonly =3D 0, rs_attrs =3D 0x10251fc0, rs_fil= ter =3D 0x10251f70, rs_filterstr =3D {bv_len =3D 18, bv_val =3D 0x10251f98 = "(uid=3D491710471677)"}}, oq_abandon =3D { rs_msgid =3D 2}, oq_cancel =3D {rs_msgid =3D 2}, oq_extended =3D {rs_= reqoid =3D {bv_len =3D 2, bv_val =3D 0x500000064 <Address 0x500000064 out o= f bounds>}, rs_flags =3D 0, rs_reqdata =3D 0x0}, oq_pwdexop =3D {rs_extended =3D {rs_reqoid =3D {bv_len =3D 2, bv_val = =3D 0x500000064 <Address 0x500000064 out of bounds>}, rs_flags =3D 0, rs_re= qdata =3D 0x0}, rs_old =3D {bv_len =3D 270868416, bv_val =3D 0x10251f70 "=A3"}, rs_new =3D {bv_len =3D 18, bv_val =3D= 0x10251f98 "(uid=3D491710471677)"}, rs_mods =3D 0x0, rs_modtail =3D 0x0}},= o_abandon =3D 0, o_cancel =3D 0, o_groups =3D 0x0, o_do_not_cache =3D 0 '\0', o_is_auth_check =3D 0 '\0', o_dont_replicate = =3D 0 '\0', o_acl_priv =3D ACL_NONE, o_nocaching =3D 0 '\0', o_delete_glue_= parent =3D 0 '\0', o_no_schema_check =3D 0 '\0', o_no_subordinate_glue =3D 0 '\0', o_ctrlflag =3D '\0' <repeats 31 times>,= o_controls =3D 0xfa01d58, o_authz =3D {sai_method =3D 128, sai_mech =3D {b= v_len =3D 0, bv_val =3D 0x0}, sai_dn =3D { bv_len =3D 51, bv_val =3D 0x2aaab89f0a50 "uid=3Dadmin,ou=3Dcms,ou=3Dp= rofiles,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, sai_ndn =3D {bv_len =3D 51, bv_val =3D 0x2aaab8a04e20 "uid=3Dadmin,ou=3Dcms,ou=3Dprofiles,ou=3Dmm= o,c=3Dde,o=3Dvodafone"}, sai_ssf =3D 0, sai_transport_ssf =3D 0, sai_tls_ss= f =3D 0, sai_sasl_ssf =3D 0}, o_ber =3D 0x2aaac8098630, o_res_ber =3D 0x0, o_callback =3D 0x4813a740, o_ctrls =3D 0x0, o_csn =3D = {bv_len =3D 0, bv_val =3D 0x0}, o_private =3D 0x0, o_extra =3D {slh_first = =3D 0x4813a480}, o_next =3D {stqe_next =3D 0x0}} (gdb) p * rs $56 =3D {sr_type =3D REP_SEARCH, sr_tag =3D 0, sr_msgid =3D 0, sr_err =3D 0= , sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr= _un =3D {sru_search =3D {r_entry =3D 0xe932208, r_attr_flags =3D 17, r_operational_attrs =3D 0x0, r_attrs =3D 0x10251= fc0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0xe93= 2208}, sru_extended =3D { r_rspoid =3D 0xe932208 "\2002\a", r_rspdata =3D 0x11}}, sr_flags =3D = 4} Frame analysis (function called) (gdb) fr 0 #0 0x0000003be7075b50 in strcpy () from /lib64/libc.so.6 (gdb) info registers rax 0x1 1 rbx 0x1 1 rcx 0x3 3 rdx 0x47f37648 1207137864 rsi 0x25 37 rdi 0x47f37648 1207137864 rbp 0x47f265e4 0x47f265e4 rsp 0x47a25518 0x47a25518 r8 0xfefefefefefefeff -72340172838076673 r9 0x4813bdd0 1209253328 r10 0x2aaab8000020 46912719814688 r11 0x206 518 r12 0xe5e2ae0 241052384 r13 0x0 0 r14 0xfa01aa0 262150816 r15 0x6 6 rip 0x3be7075b50 0x3be7075b50 <strcpy+16> eflags 0x10217 [ CF PF AF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x63 99 gs 0x0 0 (gdb) disas=20 Dump of assembler code for function strcpy: 0x0000003be7075b40 <strcpy+0>: mov %rsi,%rcx 0x0000003be7075b43 <strcpy+3>: and $0x7,%ecx 0x0000003be7075b46 <strcpy+6>: mov %rdi,%rdx 0x0000003be7075b49 <strcpy+9>: je 0x3be7075b66 <strcpy+38> 0x0000003be7075b4b <strcpy+11>: neg %ecx 0x0000003be7075b4d <strcpy+13>: add $0x8,%ecx 0x0000003be7075b50 <strcpy+16>: mov (%rsi),%al rsi is a parameter of strcpy.=20 rsi should be an address but we have 0x25 which is an invalid address. So c= rash 2010-12-05T11:22:57.643777+01:00 ts2mstsv001 kernel: 6>slapd[189000000= 000000025 rip 0000003be707p 000000 rsi is not modified in strcpy, then, check rsi calculation in template_resp= onse (gdb) fr 1 #1 0x00002b5ffe3debeb in template_response (op=3D0xfa01aa0, rs=3D0x4813bc6= 0) at /usr/include/bits/string3.h:118 118 return __builtin___strcpy_chk (__dest, __src, __bos (__dest)); (gdb) info registers rax 0x1 1 rbx 0x1 1 rcx 0x3 3 rdx 0x47f37648 1207137864 rsi 0x25 37 rdi 0x47f37648 1207137864 rbp 0x47f265e4 0x47f265e4 rsp 0x47a25520 0x47a25520 r8 0xfefefefefefefeff -72340172838076673 r9 0x4813bdd0 1209253328 r10 0x2aaab8000020 46912719814688 r11 0x206 518 r12 0xe5e2ae0 241052384 r13 0x0 0 r14 0xfa01aa0 262150816 r15 0x6 6 rip 0x2b5ffe3debeb 0x2b5ffe3debeb <template_response+3787> eflags 0x10217 [ CF PF AF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x63 99 gs 0x0 0 (gdb) disass 0x00002b5ffe3debeb Dump of assembler code for function template_response: ... 0x00002b5ffe3deb86 <template_response+3686>: lea 0x5010c4(%rsp),%rbp 0x00002b5ffe3deb8e <template_response+3694>: xor %r15d,%r15d 0x00002b5ffe3deb91 <template_response+3697>: xor %r13d,%r13d 0x00002b5ffe3deb94 <template_response+3700>: mov %rdx,0x30(%rsp) 0x00002b5ffe3deb99 <template_response+3705>: mov %rcx,0x28(%rsp) 0x00002b5ffe3deb9e <template_response+3710>: jmp 0x2b5ffe3dec07 <temp= late_response+3815> 0x00002b5ffe3deba0 <template_response+3712>: mov 0x511900(%rsp),%rax 0x00002b5ffe3deba8 <template_response+3720>: test %rax,%rax 0x00002b5ffe3debab <template_response+3723>: je 0x2b5ffe3debeb <temp= late_response+3787> 0x00002b5ffe3debad <template_response+3725>: mov 0x8(%rax),%rsi 0x00002b5ffe3debb1 <template_response+3729>: test %rsi,%rsi 0x00002b5ffe3debb4 <template_response+3732>: je 0x2b5ffe3debeb <temp= late_response+3787> 0x00002b5ffe3debb6 <template_response+3734>: cmpq $0x7ff,(%rax) 0x00002b5ffe3debbd <template_response+3741>: ja 0x2b5ffe3df966 <temp= late_response+7238> 0x00002b5ffe3debc3 <template_response+3747>: movslq 0x512124(%rsp),%rdi 0x00002b5ffe3debcb <template_response+3755>: mov 0x28(%rsp),%rdx 0x00002b5ffe3debd0 <template_response+3760>: lea 0x1(%rdi),%eax 0x00002b5ffe3debd3 <template_response+3763>: shl $0xb,%rdi 0x00002b5ffe3debd7 <template_response+3767>: lea 0x808(%rdi,%rdx,1),%= rdi 0x00002b5ffe3debdf <template_response+3775>: mov %eax,0x512124(%rsp) 0x00002b5ffe3debe6 <template_response+3782>: callq 0x2b5ffe3dc688 <strc= py@plt> 0x00002b5ffe3debeb <template_response+3787>: lea 0x1(%r13),%eax (gdb) p *(long **)($rsp+0x511900) $17 =3D (long *) 0x2aaab4859d00 (gdb) x/20x 0x2aaab4859d00 0x2aaab4859d00: 0x00000000 0x00000000 0x00000025 0x00000000 rsi is broken, not a valid address. Wolfgang Hummel

1 0

Re: (ITS#6478) slapd crashes with segfault
by hyc＠symas.com 19 Dec '10

19 Dec '10

wolfgang.hummel(a)hp.com wrote: > We managed to install it with debug-symbols now, > but did not have a new crash (yet). > > However we did a deeper anaylysis of existing > crashes. > Here is the outcome: > #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 > (gdb) thread apply all bt > > Thread 3 (process 17892): > #0 0x00000037a5a075a5 in pthread_join () from /lib64/libpthread.so.0 > #1 0x000000000043402c in slapd_daemon () at ../../../servers/slapd/daemon.= > c:2834 > #2 0x0000000000420d75 in main (argc=3D5, argv=3D0x7fff3a6ee4b8) at ../../.= > ./servers/slapd/main.c:953 > > Thread 2 (process 17894): > #0 0x00000037a5a0a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/lib= > pthread.so.0 > #1 0x000000000052fdab in ldap_pvt_thread_pool_destroy (tpool=3D0x8635e8, r= > un_pending=3D487320688) at ../../../libraries/libldap_r/tpool.c:558 > #2 0x000000000043767c in slapd_daemon_task (ptr=3D<value optimized out>) a= > t ../../../servers/slapd/daemon.c:2764 > #3 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 > #4 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 > > Thread 1 (process 17895): > #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 > #1 0x00000037a4e31ae0 in abort () from /lib64/libc.so.6 > #2 0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6 > #3 0x00000037a4e6f444 in _int_free () from /lib64/libc.so.6 > #4 0x00000037a4e72a6c in free () from /lib64/libc.so.6 > #5 0x0000000000559e07 in sb_rdahead_remove (sbiod=3D0x2aaac488d0d0) at ../= > ../../libraries/liblber/sockbuf.c:606 > #6 0x0000000000559fb9 in ber_sockbuf_free (sb=3D0x2aaac488d0d0) at ../../.= > ./libraries/liblber/sockbuf.c:71 > #7 0x0000000000000000 in ?? () This is quite unlikely to be a valid trace, since sb_rdahead_remove is only used on UDP sockets, and UDP socket support is not enabled by default nor is there a configure switch to enable 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#6751) 3rd Party Technical Support Services
by Kurt＠OpenLDAP.org 17 Dec '10

17 Dec '10

A listing for New Elements GmbH has been added. Please check it for = errors. You are welcomed to suggest changes, though note that we prefer = to keep the listings reasonably concise. In your suggested listing, it = wasn't clear to me which URL you wished me to use in your listing (only = one is allowed). If you like the other to be used, please indicate so. Regards, Kurt=

1 0

Re: (ITS#6751) 3rd Party Technical Support Services
by Kurt＠OpenLDAP.org 16 Dec '10

16 Dec '10

On Dec 16, 2010, at 4:36 AM, d.pietratus(a)newelements.de wrote: > Full_Name: David Pietratus - New Elements GmbH > Version:=20 > OS:=20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (188.111.114.162) >=20 >=20 > Dear OpenLDAP team, >=20 > We would like to appear in the 3rd Party Technical Support Services=20 > area at the OpenLDAP websitehttp://www.openldap.org/support/ > For over 10 years, IT-Schulungen.com is a recognized hotspot for many = companies > and authorities when it comes to the implementation of IT training and = IT > management in Germany, Austria and Switzerland. The portfolio of = seminars > reaches from software development, databases over network technologies = and > portals to open source technologies. One of our goals is to promote = open source > topics. > We offer OpenLDAP trainings for overview and advanced users as well as = a large > selection of other open source technologies. >=20 > We would like to appear in the 3rd Party Technical Support Services = area at the > OpenLDAP websitehttp://www.openldap.org/support/ with the following = content and > link: >=20 > http://www.it-schulungen.com - Germany IT-Schulungen.com offers=20 > OpenLDAP trainings from project experienced trainers as well as other = open > source technologies. > http://www.it-schulungen.com/seminare/opensource/openldap/index.html Your request appears to contain all the information needed for it to be = considered. The OpenLDAP Engineering Team will now consider your = application. If further information is needed, you will be contacted. = You can expect a some action (accept, deny, or defer for more = information) to be taken within the next week. Please note that if your listing is accepted it will be listed with the = heading: New Elements GmbH (IT-Shulungen.com) - Germany and with both firm name and the service name with both linked to = http://www.it-schulungen.com. The descriptive text will likely be = modified to match the style of writing of other listings. Regards, Kurt

1 0

(ITS#6751) 3rd Party Technical Support Services
by d.pietratus＠newelements.de 16 Dec '10

16 Dec '10

Full_Name: David Pietratus - New Elements GmbH Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.111.114.162) Dear OpenLDAP team, We would like to appear in the 3rd Party Technical Support Services area at the OpenLDAP websitehttp://www.openldap.org/support/ For over 10 years, IT-Schulungen.com is a recognized hotspot for many companies and authorities when it comes to the implementation of IT training and IT management in Germany, Austria and Switzerland. The portfolio of seminars reaches from software development, databases over network technologies and portals to open source technologies. One of our goals is to promote open source topics. We offer OpenLDAP trainings for overview and advanced users as well as a large selection of other open source technologies. We would like to appear in the 3rd Party Technical Support Services area at the OpenLDAP websitehttp://www.openldap.org/support/ with the following content and link: http://www.it-schulungen.com - Germany IT-Schulungen.com offers OpenLDAP trainings from project experienced trainers as well as other open source technologies. http://www.it-schulungen.com/seminare/opensource/openldap/index.html

1 0

Re: (ITS#6750) About 3rd Party Technical Support Services
by kurt＠OpenLDAP.org 16 Dec '10

16 Dec '10

On Dec 15, 2010, at 5:27 PM, harrybetter(a)qq.com wrote: > Full_Name: Jerry Liu > Version: openldap-2.4.23 > OS: RedHatLinux EL5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (221.0.151.187) >=20 >=20 > We are SeojinDSA CO,LTD. We sincerely hope to show our company name = and link > on list of "Technical Support" page. But we do not know how to apply, = I hope > this reply. By filing an ITS with your request, you have applied. > SeojinDSA is an emerging leader in the Korean field of = next-generation > Directory Service(LDAP) and Identity Managerment(IAM:Identity Access > Management=A3=A9The company's headquarter is in Seoul.Our Company is = made up of > experts and thought leaders who are recognized for building = world-class > Directory Service. A couple of questions. Please provide the URL for your website/webpage to which your listing = should be linked to? Please provide a URL to a webpage at your website which details = technical support services which are specifically tailored to users of = OpenLDAP Software? (may be same as the above URL) Please provide a summary of your current participation in the OpenLDAP = community? Please provide an email address (possibly yours) at a domain registered = to SeojinDSA we can use to confirm your association with SeojinDSA? If = you do not wish this email to be made public (all = openldap-its(a)openldap.org is public), you may send this email address = directly to me at <kurt(a)openldap.org>. (It's okay for the above requested URLs to refer to non-English web = pages.) Regards, Kurt=

1 0

(ITS#6750) About 3rd Party Technical Support Services
by harrybetter＠qq.com 16 Dec '10

16 Dec '10

Full_Name: Jerry Liu Version: openldap-2.4.23 OS: RedHatLinux EL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (221.0.151.187) We are SeojinDSA CO,LTD. We sincerely hope to show our company name and link on list of "Technical Support" page. But we do not know how to apply, I hope this reply. SeojinDSA is an emerging leader in the Korean field of next-generation Directory Service(LDAP) and Identity Managerment(IAM:Identity Access Management£©The company's headquarter is in Seoul.Our Company is made up of experts and thought leaders who are recognized for building world-class Directory Service.

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by cmikk＠qwest.net 16 Dec '10

16 Dec '10

On Sun, Dec 12, 2010 at 06:22:38PM +0100, Rein Tollevik wrote: > On 11/19/10 23:55 , cmikk(a)qwest.net wrote: > > >will evaluate to true in cases where it should not. A quick fix would be to > >compare directly against the CSN of the sessionlog's head: > > An extended version of this fix, which also ensures that the > sessionlog is kept in csn order, is now in head. Please test, > syncprov.c revision 1.320. Looks good to me. Thank you. I discovered this bug while trying to reproduce ITS#6717. I've attached a patch to that ITS which appears to fix that problem. If you have the time, I'd appreciate some feedback on that patch. The issue makes it very inefficient to run a slave in refreshOnly mode with a multimaster / mirrormode master. Best Regards, -- Chris Mikkelson | It has been said that man is a rational animal. cmikk(a)qwest.net | All my life I have been searching for evidence | which could support this. -- Bertrand Russell

1 0

(ITS#6717) patch for syncprov unnecessary presentation issue
by cmikk＠qwest.net 16 Dec '10

16 Dec '10

The following patch against servers/slapd/overlays/syncprov.c version 1.320 appears to fix the issue detailed in ITS#6717, and does not appear to break any of the basic sync functionality. --- syncprov.c.1.320 2010-12-15 19:55:32.000000000 +0000 +++ syncprov.c 2010-12-15 22:13:48.000000000 +0000 @@ -2409,7 +2409,7 @@ sync_control *srs; BerVarray ctxcsn; int i, *sids, numcsns; - struct berval mincsn; + struct berval mincsn, maxcsn; int dirty = 0; if ( !(op->o_sync_mode & SLAP_SYNC_REFRESH) ) return SLAP_CB_CONTINUE; @@ -2524,12 +2524,25 @@ i++; } - /* Find the smallest CSN */ - mincsn = srs->sr_state.ctxcsn[0]; - for ( i=1; i<srs->sr_state.numcsns; i++ ) { - if ( ber_bvcmp( &mincsn, &srs->sr_state.ctxcsn[i] ) > 0 ) - mincsn = srs->sr_state.ctxcsn[i]; + /* Find the smallest CSN which differs between cookie + * and contextCSN. + */ + mincsn.bv_len = 0; + maxcsn.bv_len = 0; + for ( i=0; i<srs->sr_state.numcsns; i++) { + for (j=0; j<numcsns; j++) { + if ( srs->sr_state.sids[i] != sids[j] ) continue; + if (BER_BVISNULL(&maxcsn) || ber_bvcmp( &maxcsn, &srs->sr_state.ctxcsn[i] ) < 0 ) { + maxcsn = srs->sr_state.ctxcsn[i]; + } + if (ber_bvcmp( &srs->sr_state.ctxcsn[i], &ctxcsn[j] ) < 0) { + if (BER_BVISNULL(&mincsn) || ber_bvcmp( &mincsn, &srs->sr_state.ctxcsn[i] ) > 0 ) { + mincsn = srs->sr_state.ctxcsn[i]; + } + } + } } + if (BER_BVISNULL(&mincsn)) mincsn = maxcsn; /* If nothing has changed, shortcut it */ if ( srs->sr_state.numcsns == numcsns ) {

1 0

(ITS#6749) Shut up "configure monitor database to enable"
by h.b.furuseth＠usit.uio.no 15 Dec '10

15 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard 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.

1 0

Re: (ITS#6747) LDAP_CONNECTIONLESS nitpicks
by Kurt＠OpenLDAP.org 14 Dec '10

14 Dec '10

My nitpick regarding this feature is that it still exists. :-) -- Kurt On Dec 14, 2010, at 6:04 AM, 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 > > > Bug: > slapd/daemon.c outputs a berval instead of berval.bv_val. > > Compiler warnings: > slapd/connection.c needs lber-int.h for ber_int_sb_read(). > libldap/<abandon.c, search.c> pass a struct sockaddr* to a char*. > > Fixing.

1 0

Re: (ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by ralf＠OpenLDAP.org 14 Dec '10

14 Dec '10

Hi, Am Dienstag 14 Dezember 2010, 12:15:04 schrieb De Bonis Hamelin, Marie Antoinette (Marian - CMS): > Hi, > > Could you please confirm/share us, modifications like moving from > strcpy() to memcpy() were done also for the bdb back-end? If yes, > could you also give us in which release fixes were committed? As mentioned in a previous comment in this ITS the fix is in r1.169 of back-bdb/dn2id.c. Back-bdb didn't need a separate fix as this issue was back-hdb specific. Otherwise it would most probably not need an extra fix as well as back-bdb and back-hdb share most of their code. -- regards, Ralf

1 0

(ITS#6748) slapo-memberof can log scrambled error text
by h.b.furuseth＠usit.uio.no 14 Dec '10

14 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard memberof_value_modify() calls op->o_bd->be_modify( &op2, &rs2 ); and then uses rs2.sr_text, which can be a value on be_modify's stack. Fixing by deleting 'text=...' from the error message.

1 0

(ITS#6747) LDAP_CONNECTIONLESS nitpicks
by h.b.furuseth＠usit.uio.no 14 Dec '10

14 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Bug: slapd/daemon.c outputs a berval instead of berval.bv_val. Compiler warnings: slapd/connection.c needs lber-int.h for ber_int_sb_read(). libldap/<abandon.c, search.c> pass a struct sockaddr* to a char*. Fixing.

1 0

Re: (ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth＠usit.uio.no 14 Dec '10

14 Dec '10

I've fixed it in HEAD, unless early errors in translucent_search() should be ignored or filter errors should NOT be ignored. -- Hallvard

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 13 Dec '10

13 Dec '10

Could we have this overlay in contrib/ shipped with 2.4.24? That would be really nice. I've tested it with 2.4.23 and it still seems to work.

1 0

Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by rmeggins＠redhat.com 13 Dec '10

13 Dec '10

On 12/10/2010 09:03 PM, Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> I "rebased" the patch on top of a recent change: >> revision 1.24 >> date: 2010/12/06 10:31:59; author: hallvard; state: Exp; lines: +5 >> -17 >> ITS#6625 Remove some LDAP_R_COMPILEs > > I didn't quite understand the point of the discussion of SSLv2 clients > in the comments on this patch, but committed it anyway. Thanks. I usually defer to Bob Relyea - he insists this is secure, and will not use SSLv2 if it is explicitly disabled (which it is in the OpenLDAP implementation). > > I would hope that nobody is still using SSLv2 these days. Also if a > StartTLS request fails, then the rest of the code in tlsm.c should > never even be reached; the TLS sockbuf layer wouldn't be installed. In my testing, openldap server was calling the tls session_accept function after the client failed to start tls. Because the failure was on the client side (e.g. a bogus CA cert), the server left the connection flagged with c_needs_tls_accept, and called ldap_pvt_tls_accept() on the next read. I've confirmed this using both openldap 2.4 with openssl and with moznss. openssl also checks for sslv2 incoming connections, but handles error cases better (e.g. it looks for http connections), including the case where the header bytes don't match a known sslv2, v3, or tls handshake. See ssl23_get_client_hello() for more information. > >> The new patch is here: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… >> >> >> This patch file is derived from OpenLDAP Software. All of the >> modifications to OpenLDAP Software represented in the following >> patch(es) were developed by Red Hat. Red Hat has not assigned rights >> and/or interest in this work to any party. I, Rich Megginson am >> authorized by Red Hat, my employer, to release this work under the >> following terms. >> >> Red Hat hereby place the following modifications to OpenLDAP Software >> (and only these modifications) into the public domain. Hence, these >> modifications may be freely used and/or redistributed for any purpose >> with or without attribution and/or other notice. >> >> >> >> > >

1 0

Re: (ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

I wrote: > translucent_search() can return LDAP_COMPARE_FALSE from test_filter(). ...and other error codes too. Should it ignore all other result codes from test_filter() than LDAP_COMPARE_TRUE? -- Hallvard

1 0

(ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard translucent_search() can return LDAP_COMPARE_FALSE from test_filter(). Should presumably be LDAP_SUCCESS. It should probably either ignore rc from overlay_op_walk() or not. Currently it ignores rc only if there are entries in tc.list. It doesn't seem to free the remaining entries in tc.list after send_search_entry() failure.

1 0

(ITS#6745) HEAD emfile race condition -> slapd stopping listening?
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard In HEAD slapd/daemon.c, thanks to HEAD's multiple listener support: slap_listener() protects emfile with slap_daemon[0 ].sd_mutex, but slapd_remove() protects it with slap_daemon[id].sd_mutex. Maybe to compensate, slapd_remove() has code which checks if emfile is too big, but nothing checks if it is too small - which looks like slapd might never start listening again. Simplest fix: add this to slapd_remove(): if (id) ldap_pvt_thread_mutex_<lock,unlock>( &slap_daemon[0].sd_mutex ); slap_daemon[0].sd_mutex looks quite contended that way, though. Maybe a separate emfile_mutex is better.

1 0

Re: (ITS#6476) Failure to delete entry with multi-master replication
by piotr.tarnowski＠us.edu.pl 13 Dec '10

13 Dec '10

Hi! We have observed similiar symptoms with OpenLDAP 2.4.23: 2010-12-10T14:56:45+01:00 ldapst2/192.168.10.48 slapd[29363]: [ID 502419 local4.debug] Entry uid=Replicator,dc=us,dc=edu,dc=pl CSN 2 0101208130342.415481Z#000000#008#000000 older or equal to ctx 20101208130342.415481Z#000000#008#000000 2010-12-10T14:56:45+01:00 ldapst2/192.168.10.48 slapd[29363]: [ID 653192 local4.debug] syncprov_search_response: cookie=rid=008,sid= 008,csn=20101202144622.962136Z#000000#007#000000;20101001125631.576652Z#000000#003#000000;20101210135344.096897Z#000000#008#000000 do you have any fixes? Regards -- [ Piotr Tarnowski piotr.tarnowski(a)us.edu.pl ] [ Unix Administrator, University of Silesia, Katowice, Poland ]

1 0

Re: (ITS#6731) Scrambled error strings from back-ldif
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Howard Chu writes: > It is not an error in ldif_back_add() since rs->sr_text is only used by > send_ldap_result(). Its value upon return from ldif_back_add is irrelevant. Should have been true but isn't - a number of modules reuse SlapReply variables without clearing them:-( -- Hallvard

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

I suppose it could be old misnamed ITS#5340. If so, try http://folk.uio.no/hbf/OpenLDAP/slapreply-draft3.diff Compile with CPPFLAGS="-DRS_USE_ASSERT=0". If that helps, the patch needs to work without the CPPFLAGS, but the asserts may be overeager. -- Hallvard

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 12 Dec '10

12 Dec '10

On 11/19/10 23:55 , cmikk(a)qwest.net wrote: > will evaluate to true in cases where it should not. A quick fix would be to > compare directly against the CSN of the sessionlog's head: An extended version of this fix, which also ensures that the sessionlog is kept in csn order, is now in head. Please test, syncprov.c revision 1.320. Rein

1 0

Re: (ITS#6744) memory leak when chasing referrals
by arthur＠arthurdejong.org 11 Dec '10

11 Dec '10

--=-dGqU1ahV0Ya5KsADLt/0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2010-12-10 at 19:52 -0800, Howard Chu wrote: > Thanks, reproduced using ldapsearch. Fixed in HEAD. Thanks for the quick response and fix! --=20 -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org -- --=-dGqU1ahV0Ya5KsADLt/0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJNA/gRAAoJECqLdGgQ4K/B3hQP+wbUpmAAws3D7aobKrff+lm1 fe6Bl2kSh/xr7YJptDHQsQf0u7ZfuWPBY7Jm/VYR6vjBqfn2do2J4yZL2yKbkKJS Js9ir23JBgg5hv/qi9c64uA85GTU0NPex7PcWP45y5Y95ZBtDsdGBzvuoePwGCvn Wkb3dNY1Cl6MDL77CZPyoy1qKRHWcWPfVONhbLkQ5LF2BuDPV1dXjFSV1mqRTbLr JXqn1QKYrdRhHhIkZsdXs8RmdtWZ+43lZyqpF2jGtLR3iP8e55kPluih35Mp/fWM 1L/dVYjQO8sV54b1UPGJKAIDHoqacXhRgCZgRTJxQZy3GJ8eKmuM7G4O71TpYuX5 AoxXDcuSOuBY7qDFfTUkICujNDWHXQ0C4/nzN6owyPc5TneXGeJYMgzmyctZb5et jhLwAuS2kwDGNL46XxyuGSF+cDSEeEFxpewo61cXFB/gp2+469MCWfoyWtyp/LHV MZwpTAz9B0FvDjPMOMqd91h4O1WZIxBBo61FnL2iPWD/pNHrmQXlTTQ/y/WMHIXg bWkjqbnT8Qi1PpFYgvo2u+6oe1U4tV6aNRwioQjVyVi8lK+tyC9EL+tJfAGq5f7H JqOZj37PJ5qd26DUU6q2vX7r7RO7wX8TraP0/Kafvg2FnVk+9G+1LSdmjwzviPBp 32EBHtl1GZlq7rP4Q+zm =74Se -----END PGP SIGNATURE----- --=-dGqU1ahV0Ya5KsADLt/0--

1 0

Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by hyc＠symas.com 11 Dec '10

11 Dec '10

rmeggins(a)redhat.com wrote: > I "rebased" the patch on top of a recent change: > revision 1.24 > date: 2010/12/06 10:31:59; author: hallvard; state: Exp; lines: +5 -17 > ITS#6625 Remove some LDAP_R_COMPILEs I didn't quite understand the point of the discussion of SSLv2 clients in the comments on this patch, but committed it anyway. I would hope that nobody is still using SSLv2 these days. Also if a StartTLS request fails, then the rest of the code in tlsm.c should never even be reached; the TLS sockbuf layer wouldn't be installed. > The new patch is here: > ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… > > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6744) memory leak when chasing referrals
by hyc＠symas.com 11 Dec '10

11 Dec '10

arthur(a)arthurdejong.org wrote: > Full_Name: Arthur de Jong > Version: 2.4.23 > OS: Debian > URL: > Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) > > > There seems to be a memory leak in the LDAP client library when casing > referrals. When the code below is run through valgrind it reports: > > ==30395== 4,184 (80 direct, 4,104 indirect) bytes in 1 blocks are definitely > lost in loss record 3 of 3 > ==30395== at 0x402328F: calloc (vg_replace_malloc.c:467) > ==30395== by 0x41D2CDF: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.6) > ==30395== by 0x40650A0: ldap_send_server_request (in > /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x4065EB1: ldap_chase_v3referrals (in > /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x40510A3: ldap_result (in /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x8048871: main (test.c:28) > > The code below is not very pretty (does not include error handling) but should > free all returned buffers. I can also reproduce the above leak with the > ldapsearch command-line tool. Thanks, reproduced using ldapsearch. 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#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 11 Dec '10

11 Dec '10

On Dec 10, 2010, at 5:16 PM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' >> DESC 'last successful authentication using any method/mech' >> EQUALITY generalizedTimeMatch >> ORDERING generalizedTimeOrderingMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 >> SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) >>=20 >> And we use this attribute in our configuration object to = enable/disable =3D >> (default disabled). >>=20 >> ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' >> DESC 'enable recording of last successful authentication using =3D= >> any method/mech' >> EQUALITY booleanMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 >> SINGLE-VALUE USAGE dsaOperation ) >=20 > Hmm, isn't NAME of the second a little bit confusing since it sounds = like just > the plural of the first? Names should only be for the wire, the wire doesn't get confused. -- Kurt=

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 11 Dec '10

11 Dec '10

Kurt(a)OpenLDAP.org wrote: > ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' > DESC 'last successful authentication using any method/mech' > EQUALITY generalizedTimeMatch > ORDERING generalizedTimeOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 > SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) > > And we use this attribute in our configuration object to enable/disable = > (default disabled). > > ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' > DESC 'enable recording of last successful authentication using = > any method/mech' > EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 > SINGLE-VALUE USAGE dsaOperation ) Hmm, isn't NAME of the second a little bit confusing since it sounds like just the plural of the first? Ciao, Michael.

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 12:02 PM, Howard Chu wrote: > Good point. In that case it's probably fine as a separate overlay, the = way it is now. Can we use the schema definition that Isode is using? Not only yes, but hell yes. Reuse and convergence is a good thing. ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' DESC 'last successful authentication using any method/mech' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) And we use this attribute in our configuration object to enable/disable = (default disabled). ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' DESC 'enable recording of last successful authentication using = any method/mech' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE dsaOperation )

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs