openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by Laurent.LeGrandois＠atos.net 29 Mar '12

29 Mar '12

This is a multi-part message in MIME format. --------------060203070300020608020002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Le 29/03/2012 15:14, hyc(a)symas.com a =E9crit : > Laurent.LeGrandois(a)atos.net wrote: >> This is a multi-part message in MIME format. >> --------------070001090703090002060300 >> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >> Content-Transfer-Encoding: quoted-printable >> >> Hi, >> >> any news concerning integration of this patch ? > An alternate patch is now in git master, please test. Ok, we will test it : any modifications to do for 2.4.28 version ? Thanks >> Thanks >> >> Laurent Le Grandois >> >> >> Le 06/02/2012 18:23, jiashun.qian(a)atos.net a =3DE9crit : >>> Now the new patch encode the binary data to base64 by using slap_ad_i= s_=3D >> binary to check if it's binary data, and using lutil_b64_ntop for the = enc=3D >> ode. > --=20 Cordialement, *Laurent Le Grandois <http://people.portaildulibre.fr/%7Ellg/qr-code.png>= * Architecte Open Source Campus AtoS - River Ouest Pacific 3 Sud 8 +33 (0) 1 73 26 16 32 +33 (0) 6 70 01 25 61 80, Quai Voltaire 95877 Bezons Cedex Signature IOC <http://www.atos.net> --------------060203070300020608020002 Content-Type: multipart/related; boundary="------------050102040904060500010807" --------------050102040904060500010807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> Le 29/03/2012 15:14, <a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> a écrit : <blockquote cite="mid:201203291314.q2TDEUiO066709@boole.openldap.org" type="cite"> <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:Laurent.LeGrandois@atos.net">Laurent.LeGrandois(a)atos.net</a> wrote: </pre> <blockquote type="cite"> <pre wrap="">This is a multi-part message in MIME format. --------------070001090703090002060300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, any news concerning integration of this patch ? </pre> </blockquote> <pre wrap=""> An alternate patch is now in git master, please test.</pre> </blockquote> Ok, we will test it : any modifications to do for 2.4.28 version ? <br> Thanks<br> <blockquote cite="mid:201203291314.q2TDEUiO066709@boole.openldap.org" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> Thanks Laurent Le Grandois Le 06/02/2012 18:23, <a class="moz-txt-link-abbreviated" href="mailto:jiashun.qian@atos.net">jiashun.qian(a)atos.net</a> a =E9crit : </pre> <blockquote type="cite"> <pre wrap="">Now the new patch encode the binary data to base64 by using slap_ad_is_= </pre> </blockquote> <pre wrap="">binary to check if it's binary data, and using lutil_b64_ntop for the enc= ode. </pre> <blockquote type="cite"> <pre wrap=""> </pre> </blockquote> </blockquote> <pre wrap=""> </pre> </blockquote> <br> <br> <div class="moz-signature">-- <br> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <div class="moz-signature"><br> <font face="CMU Sans Serif"> Cordialement,<br> <img src="cid:part1.08050501.09040401@atos.net" border="0"><br> <br> <b><a href="http://people.portaildulibre.fr/%7Ellg/qr-code.png">Laurent Le Grandois</a></b><br> <font style="font-size: 8pt;"> <br> Architecte Open Source<br> <br> Campus AtoS - River Ouest<br> Pacific 3 Sud 8<br> +33 (0) 1 73 26 16 32<br> +33 (0) 6 70 01 25 61<br> 80, Quai Voltaire 95877 Bezons Cedex<br> </font> </font> <a href="http://www.atos.net"> <img src="cid:part3.07070802.03040503@atos.net" alt="Signature IOC" border="0"></a> </div> </div> </body> </html> --------------050102040904060500010807 Content-Type: image/gif; name="blue_strip.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.08050501.09040401(a)atos.net> Content-Disposition: inline; filename="blue_strip.gif" R0lGODlhgAADAKIAAABnoX+z0ECNuZ/G3P///wAAAAAAAAAAACH5BAEAAAQALAAAAACAAAMA AAMTCLrc/jDKSau9OOvNu/9gKI5OAgA7 --------------050102040904060500010807 Content-Type: image/gif; name="atos_logo_small.gif" Content-Transfer-Encoding: base64 Content-ID: <part3.07070802.03040503(a)atos.net> Content-Disposition: inline; filename="atos_logo_small.gif" R0lGODlhgAAlAMQAAABnoX9/f7/Z53+z0ECNuRBxp9/s8+/1+Z/G3M/i7SB6rTCEs2CgxK/P 4nCqyo+81lCXvt/f37+/v////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAEAABMALAAAAACAACUAAAX/YCCOZGmeaKqubOu+6CTPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16fQaBOPHlAc7oNACRE6gF0MODoD4XCA52uVZXE9pvTwMFfXV7 fIVoBjhuaXBMB3SJaoc0AwOSfQ+MgT0HlwMNizgMk2oFlTULiQs0CQSwq2kLsLU1nwwTpbN6 rnUKeWIImX+pMganaqMTjaZnNA2EooUEyxMOark1A2jFxthoELtoDjPNzjPgqOB9BWQymQAK N9xn3qkKaQgNavMy56Zk1APwJ18id/DS+NvWzdiEBGkKHJhgEM07A6DGnWEA6hKzNAMmqIFA SOHEeAC0/90w8C4Vu5QyXsKsAfARjYprAE4wIAtNSI1nFPRyaKPkmQYyIEa0UbMGgjc6Jxzo CUAiQDTAWhKdwA8Nqhk4ASCl0ZQGhFkf08xQioYNyn4DrKXSWG7GwI00O81Qo0dNy7Nock11 xmBiqgNGAWhFFtHwP70P1RimqvJpQ4GJ2409ZDmoDapryEI+t/Cu4sdeaXwKW0frF8DOwol2 NPtMq2OnyESt0YABa3uHDsSu47gsajSWTj14kOaejQZvAcjl0nn4mU3Hz9iUoWbz4EkQeESD 3AX08Ntp0WyfQPXe90JDc8hcv4UxmgZi8uvPPArgZhnVAYCdDO8R14Np9GnB3K1lpKiBHUAq 4cbXNpnBZEBWOCTAXxlUxcdbPxKmMSACvxHQwEQGPJCZRLp4BUEoYjwAGxro1SdAgPhleBUC AhQYFAEVWgfHVc4keIVpat0QnXZdmWJeIno8OUldXSCJnJKJwCFTHWxY2c87BwA1SQEeauEl ADgsCcAjDZTYkgFiBhVSDSlKaYcD09mon3467pmfY8x0hECeBzQwAAMEXOKaDQcI8EBHAzyw qBchAAA7 --------------050102040904060500010807-- --------------060203070300020608020002--

1 0

Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by hyc＠symas.com 29 Mar '12

29 Mar '12

Laurent.LeGrandois(a)atos.net wrote: > This is a multi-part message in MIME format. > --------------070001090703090002060300 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: quoted-printable > > Hi, > > any news concerning integration of this patch ? An alternate patch is now in git master, please test. > > Thanks > > Laurent Le Grandois > > > Le 06/02/2012 18:23, jiashun.qian(a)atos.net a =E9crit : >> Now the new patch encode the binary data to base64 by using slap_ad_is_= > binary to check if it's binary data, and using lutil_b64_ntop for the enc= > ode. >> -- -- 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#7182) back-ldap monitoring improvements
by ondrej.kuznik＠acision.com 29 Mar '12

29 Mar '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/27/2012 01:30 PM, hyc(a)symas.com wrote: > ondrej.kuznik(a)acision.com wrote: >> Full_Name: Ondrej Kuznik >> Version: HEAD >> OS: Linux >> > I have pushed patches 1-3 to git master. patch 4 seems to require additional work. I have reworked the remaining patches according to your suggestions, the resulting patchset is at: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120329-back-ldap-monitoring… The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk90XwAACgkQ9GWxeeH+cXuruQCfenFjCDLAbx+kk/jzpoogGGu5 YLoAn1SwLfVvCZtl1SHEQsuSyi+bAThP =8OdU -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by Laurent.LeGrandois＠atos.net 29 Mar '12

29 Mar '12

This is a multi-part message in MIME format. --------------070001090703090002060300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, any news concerning integration of this patch ? Thanks Laurent Le Grandois Le 06/02/2012 18:23, jiashun.qian(a)atos.net a =E9crit : > Now the new patch encode the binary data to base64 by using slap_ad_is_= binary to check if it's binary data, and using lutil_b64_ntop for the enc= ode. > > > *** ../openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11= -25 19:52:29.000000000 +0100 > --- servers/slapd/back-perl/modify.c 2012-02-06 17:41:44.638861010 += 0100 > *************** > *** 16,21 **** > --- 16,22 ---- > */ > > #include "perl_back.h" > + #include "lutil.h" > > int > perl_back_modify( > *************** > *** 26,31 **** > --- 27,33 ---- > Modifications *modlist =3D op->orm_modlist; > int count; > int i; > + struct berval b64_data; > > PERL_SET_CONTEXT( PERL_INTERPRETER ); > ldap_pvt_thread_mutex_lock(&perl_interpreter_mutex ); > *************** > *** 61,67 **** > mods->sm_values !=3D NULL&& mods->sm_= values[i].bv_val !=3D NULL; > i++ ) > { > ! XPUSHs(sv_2mortal(newSVpv( mods->sm_val= ues[i].bv_val, 0 ))); > } > > /* Fix delete attrib without value. */ > --- 63,80 ---- > mods->sm_values !=3D NULL&& mods->sm_= values[i].bv_val !=3D NULL; > i++ ) > { > ! if ( slap_ad_is_binary(mods->sm_desc) )= { > ! b64_data.bv_len =3D LUTIL_BASE6= 4_ENCODE_LEN(mods->sm_values[i].bv_len) + 1; > ! b64_data.bv_val =3D ber_memallo= c( b64_data.bv_len + 1 ); > ! b64_data.bv_len =3D lutil_b64_n= top( > ! (unsigned char = *) mods->sm_values[i].bv_val, > ! mods->sm_values= [i].bv_len, > ! b64_data.bv_val= , b64_data.bv_len ); > ! XPUSHs(sv_2mortal(newSVpv( b64_= data.bv_val, 0 ))); > ! ber_memfree( b64_data.bv_val ); > ! } else { > ! XPUSHs(sv_2mortal(newSVpv( mods= ->sm_values[i].bv_val, 0 ))); > ! } > } > > /* Fix delete attrib without value. */ > > > *** ../openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11= -25 19:52:29.000000000 +0100 > --- servers/slapd/back-shell/modify.c 2012-02-06 17:40:14.861837487 += 0100 > *************** > *** 37,42 **** > --- 37,43 ---- > > #include "slap.h" > #include "shell.h" > + #include "lutil.h" > > int > shell_back_modify( > *************** > *** 50,55 **** > --- 51,57 ---- > Entry e; > FILE *rfp, *wfp; > int i; > + struct berval b64_data; > > if ( si->si_modify =3D=3D NULL ) { > send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM, > *************** > *** 105,112 **** > > if( mod->sm_values !=3D NULL ) { > for ( i =3D 0; mod->sm_values[i].bv_val !=3D N= ULL; i++ ) { > ! fprintf( wfp, "%s: %s\n", mod->sm_desc-= >ad_cname.bv_val, > ! mod->sm_values[i].bv_val /* bin= ary! */ ); > } > } > > --- 107,126 ---- > > if( mod->sm_values !=3D NULL ) { > for ( i =3D 0; mod->sm_values[i].bv_val !=3D N= ULL; i++ ) { > ! if ( slap_ad_is_binary(mod->sm_desc) ) = { > ! b64_data.bv_len =3D LUTIL_BASE6= 4_ENCODE_LEN(mod->sm_values[i].bv_len) + 1; > ! b64_data.bv_val =3D ber_memallo= c( b64_data.bv_len + 1 ); > ! b64_data.bv_len =3D lutil_b64_n= top( > ! (unsigned char = *) mod->sm_values[i].bv_val, > ! mod->sm_values[= i].bv_len, > ! b64_data.bv_val= , b64_data.bv_len ); > ! fprintf( wfp, "%s: %s\n", mod->= sm_desc->ad_cname.bv_val, > ! b64_data.bv_val ); > ! ber_memfree( b64_data.bv_val ); > ! } else { > ! fprintf( wfp, "%s: %s\n", mod->= sm_desc->ad_cname.bv_val, > ! mod->sm_values[i].bv_va= l ); > ! } > } > } > > > ________________________________________ > De : openldap-bugs-bounces(a)OpenLDAP.org [openldap-bugs-bounces@OpenLDAP= .org] de la part de hyc(a)symas.com [hyc(a)symas.com] > Date d'envoi : jeudi 2 f=E9vrier 2012 21:44 > =C0 : openldap-its(a)openldap.org > Objet : Re: (ITS#7149) Back-perl, Back-shell and Binary Data > > llg(a)portaildulibre.fr wrote: >> Le 02/02/2012 20:32, hyc(a)symas.com a =E9crit : >>> jiashun.qian(a)atos.net wrote: >>>> Full_Name: Jiashun QIAN >>>> Version: 2.4.28 >>>> OS: CentOS 6 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (85.115.60.180) >>>> >>>> >>>> The backend shell and the backend perl can't handle some binary data= . >>>> >>>> This occurs only with MODIFY because when ADD the binary data is enc= oded in >>>> base64 but not MODIFY. >>>> >>>> The binary data is truncated when if it contains \0. In fact, data i= s stored in >>>> a linked list of char * and treated as characters. >>>> >>>> --- >>>> servers/slapd/back-perl/modify.c >>>> XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); >>>> --- >>>> >>>> The type of mods->sm_values[i].bv_val is char*. >>>> >>>> To handle the binary data, for back-perl, just change another functi= on mXPUSHp, >>>> which we can put the exacte length of mod->sm_values[i].bv_val as pa= rameter, >>>> it's mod->sm_values[i].bv_len. So it will push the total data. >>> That is obviously the wrong approach. Since these backends communicat= e using >>> LDIF, binary values should be base64 encoded according to the LDIF ru= les. >> The input LDIF file for ldap_modify contains base64 encoded >> usercertificate, but back-perl receives binary data. >> This behaviour only occured with modification action : with add action= , >> certificate is received base64 encoded. > Yes, I already understood that. You're still not understanding what I s= aid. > Your patch should do the appropriate checks for binary data and do the = proper > base64 encoding for the modify values that back-perl (or back-shell) se= nds to > the perl module (or shell script). > > This has nothing to do with the input LDIF file, this is about how slap= d > transmits internal data from a backend to the external perl or shell sc= ripts. > >>> Thanks for the patch, but we can't merge it since the provided soluti= on is wrong. > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > ________________________________ > > > Ce message et les pi=E8ces jointes sont confidentiels et r=E9serv=E9s =E0= l'usage exclusif de ses destinataires. Il peut =E9galement =EAtre prot=E9= g=E9 par le secret professionnel. Si vous recevez ce message par erreur, = merci d'en avertir imm=E9diatement l'exp=E9diteur et de le d=E9truire. L'= int=E9grit=E9 du message ne pouvant =EAtre assur=E9e sur Internet, la res= ponsabilit=E9 du groupe Atos ne pourra =EAtre engag=E9e quant au contenu = de ce message. Bien que les meilleurs efforts soient faits pour maintenir= cette transmission exempte de tout virus, l'exp=E9diteur ne donne aucune= garantie =E0 cet =E9gard et sa responsabilit=E9 ne saurait =EAtre engag=E9= e pour tout dommage r=E9sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended so= lely for the addressee; it may also be privileged. If you receive this e-= mail in error, please notify the sender immediately and destroy it. As it= s integrity cannot be secured on the Internet, the Atos group liability c= annot be triggered for the message content. Although the sender endeavors= to maintain a computer virus-free network, the sender does not warrant t= hat this transmission is virus-free and will not be liable for any damage= s resulting from any virus transmitted. > > --=20 Cordialement, *Laurent Le Grandois <http://people.portaildulibre.fr/%7Ellg/qr-code.png>= * Architecte Open Source Campus AtoS - River Ouest Pacific 3 Sud 8 +33 (0) 1 73 26 16 32 +33 (0) 6 70 01 25 61 80, Quai Voltaire 95877 Bezons Cedex Signature IOC <http://www.atos.net> --------------070001090703090002060300 Content-Type: multipart/related; boundary="------------050007050004070007020800" --------------050007050004070007020800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi,<br> <br>   any news concerning integration of this patch ? <br> <br> Thanks<br> <br> Laurent Le Grandois<br> <br> <br> Le 06/02/2012 18:23, <a class="moz-txt-link-abbreviated" href="mailto:jiashun.qian@atos.net">jiashun.qian(a)atos.net</a> a écrit : <blockquote cite="mid:201202061723.q16HNLgD077070@boole.openldap.org" type="cite"> <pre wrap="">Now the new patch encode the binary data to base64 by using slap_ad_is_binary to check if it's binary data, and using lutil_b64_ntop for the encode. *** ../openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11-25 19:52:29.000000000 +0100 --- servers/slapd/back-perl/modify.c 2012-02-06 17:41:44.638861010 +0100 *************** *** 16,21 **** --- 16,22 ---- */ #include "perl_back.h" + #include "lutil.h" int perl_back_modify( *************** *** 26,31 **** --- 27,33 ---- Modifications *modlist = op->orm_modlist; int count; int i; + struct berval b64_data; PERL_SET_CONTEXT( PERL_INTERPRETER ); ldap_pvt_thread_mutex_lock( &perl_interpreter_mutex ); *************** *** 61,67 **** mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); } /* Fix delete attrib without value. */ --- 63,80 ---- mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! if ( slap_ad_is_binary(mods->sm_desc) ) { ! b64_data.bv_len = LUTIL_BASE64_ENCODE_LEN(mods->sm_values[i].bv_len) + 1; ! b64_data.bv_val = ber_memalloc( b64_data.bv_len + 1 ); ! b64_data.bv_len = lutil_b64_ntop( ! (unsigned char *) mods->sm_values[i].bv_val, ! mods->sm_values[i].bv_len, ! b64_data.bv_val, b64_data.bv_len ); ! XPUSHs(sv_2mortal(newSVpv( b64_data.bv_val, 0 ))); ! ber_memfree( b64_data.bv_val ); ! } else { ! XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); ! } } /* Fix delete attrib without value. */ *** ../openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11-25 19:52:29.000000000 +0100 --- servers/slapd/back-shell/modify.c 2012-02-06 17:40:14.861837487 +0100 *************** *** 37,42 **** --- 37,43 ---- #include "slap.h" #include "shell.h" + #include "lutil.h" int shell_back_modify( *************** *** 50,55 **** --- 51,57 ---- Entry e; FILE *rfp, *wfp; int i; + struct berval b64_data; if ( si->si_modify == NULL ) { send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM, *************** *** 105,112 **** if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! mod->sm_values[i].bv_val /* binary! */ ); } } --- 107,126 ---- if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! if ( slap_ad_is_binary(mod->sm_desc) ) { ! b64_data.bv_len = LUTIL_BASE64_ENCODE_LEN(mod->sm_values[i].bv_len) + 1; ! b64_data.bv_val = ber_memalloc( b64_data.bv_len + 1 ); ! b64_data.bv_len = lutil_b64_ntop( ! (unsigned char *) mod->sm_values[i].bv_val, ! mod->sm_values[i].bv_len, ! b64_data.bv_val, b64_data.bv_len ); ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! b64_data.bv_val ); ! ber_memfree( b64_data.bv_val ); ! } else { ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! mod->sm_values[i].bv_val ); ! } } } ________________________________________ De : <a class="moz-txt-link-abbreviated" href="mailto:openldap-bugs-bounces@OpenLDAP.org">openldap-bugs-bounces(a)OpenLDAP.org</a> [<a class="moz-txt-link-abbreviated" href="mailto:openldap-bugs-bounces@OpenLDAP.org">openldap-bugs-bounces(a)OpenLDAP.org</a>] de la part de <a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> [<a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a>] Date d'envoi : jeudi 2 février 2012 21:44 À : <a class="moz-txt-link-abbreviated" href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a> Objet : Re: (ITS#7149) Back-perl, Back-shell and Binary Data <a class="moz-txt-link-abbreviated" href="mailto:llg@portaildulibre.fr">llg(a)portaildulibre.fr</a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Le 02/02/2012 20:32, <a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> a écrit : </pre> <blockquote type="cite"> <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:jiashun.qian@atos.net">jiashun.qian(a)atos.net</a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Full_Name: Jiashun QIAN Version: 2.4.28 OS: CentOS 6 URL: <a class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> Submission from: (NULL) (85.115.60.180) The backend shell and the backend perl can't handle some binary data. This occurs only with MODIFY because when ADD the binary data is encoded in base64 but not MODIFY. The binary data is truncated when if it contains \0. In fact, data is stored in a linked list of char * and treated as characters. --- servers/slapd/back-perl/modify.c XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); --- The type of mods->sm_values[i].bv_val is char*. To handle the binary data, for back-perl, just change another function mXPUSHp, which we can put the exacte length of mod->sm_values[i].bv_val as parameter, it's mod->sm_values[i].bv_len. So it will push the total data. </pre> </blockquote> <pre wrap="">That is obviously the wrong approach. Since these backends communicate using LDIF, binary values should be base64 encoded according to the LDIF rules. </pre> </blockquote> <pre wrap="">The input LDIF file for ldap_modify contains base64 encoded usercertificate, but back-perl receives binary data. This behaviour only occured with modification action : with add action, certificate is received base64 encoded. </pre> </blockquote> <pre wrap=""> Yes, I already understood that. You're still not understanding what I said. Your patch should do the appropriate checks for binary data and do the proper base64 encoding for the modify values that back-perl (or back-shell) sends to the perl module (or shell script). This has nothing to do with the input LDIF file, this is about how slapd transmits internal data from a backend to the external perl or shell scripts. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Thanks for the patch, but we can't merge it since the provided solution is wrong. </pre> </blockquote> </blockquote> <pre wrap=""> -- -- Howard Chu CTO, Symas Corp. <a class="moz-txt-link-freetext" href="http://www.symas.com">http://www.symas.com</a> Director, Highland Sun <a class="moz-txt-link-freetext" href="http://highlandsun.com/hyc/">http://highlandsun.com/hyc/</a> Chief Architect, OpenLDAP <a class="moz-txt-link-freetext" href="http://www.openldap.org/project/">http://www.openldap.org/project/</a> ________________________________ Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. </pre> </blockquote> <br> <div class="moz-signature">-- <br> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <div class="moz-signature"><br> <font face="CMU Sans Serif"> Cordialement,<br> <img src="cid:part1.08020906.06070706@atos.net" border="0"><br> <br> <b><a href="http://people.portaildulibre.fr/%7Ellg/qr-code.png">Laurent Le Grandois</a></b><br> <font style="font-size: 8pt;"> <br> Architecte Open Source<br> <br> Campus AtoS - River Ouest<br> Pacific 3 Sud 8<br> +33 (0) 1 73 26 16 32<br> +33 (0) 6 70 01 25 61<br> 80, Quai Voltaire 95877 Bezons Cedex<br> </font> </font> <a href="http://www.atos.net"> <img src="cid:part3.07050008.03070309@atos.net" alt="Signature IOC" border="0"></a> </div> </div> </body> </html> --------------050007050004070007020800 Content-Type: image/gif; name="blue_strip.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.08020906.06070706(a)atos.net> Content-Disposition: inline; filename="blue_strip.gif" R0lGODlhgAADAKIAAABnoX+z0ECNuZ/G3P///wAAAAAAAAAAACH5BAEAAAQALAAAAACAAAMA AAMTCLrc/jDKSau9OOvNu/9gKI5OAgA7 --------------050007050004070007020800 Content-Type: image/gif; name="atos_logo_small.gif" Content-Transfer-Encoding: base64 Content-ID: <part3.07050008.03070309(a)atos.net> Content-Disposition: inline; filename="atos_logo_small.gif" R0lGODlhgAAlAMQAAABnoX9/f7/Z53+z0ECNuRBxp9/s8+/1+Z/G3M/i7SB6rTCEs2CgxK/P 4nCqyo+81lCXvt/f37+/v////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAEAABMALAAAAACAACUAAAX/YCCOZGmeaKqubOu+6CTPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16fQaBOPHlAc7oNACRE6gF0MODoD4XCA52uVZXE9pvTwMFfXV7 fIVoBjhuaXBMB3SJaoc0AwOSfQ+MgT0HlwMNizgMk2oFlTULiQs0CQSwq2kLsLU1nwwTpbN6 rnUKeWIImX+pMganaqMTjaZnNA2EooUEyxMOark1A2jFxthoELtoDjPNzjPgqOB9BWQymQAK N9xn3qkKaQgNavMy56Zk1APwJ18id/DS+NvWzdiEBGkKHJhgEM07A6DGnWEA6hKzNAMmqIFA SOHEeAC0/90w8C4Vu5QyXsKsAfARjYprAE4wIAtNSI1nFPRyaKPkmQYyIEa0UbMGgjc6Jxzo CUAiQDTAWhKdwA8Nqhk4ASCl0ZQGhFkf08xQioYNyn4DrKXSWG7GwI00O81Qo0dNy7Nock11 xmBiqgNGAWhFFtHwP70P1RimqvJpQ4GJ2409ZDmoDapryEI+t/Cu4sdeaXwKW0frF8DOwol2 NPtMq2OnyESt0YABa3uHDsSu47gsajSWTj14kOaejQZvAcjl0nn4mU3Hz9iUoWbz4EkQeESD 3AX08Ntp0WyfQPXe90JDc8hcv4UxmgZi8uvPPArgZhnVAYCdDO8R14Np9GnB3K1lpKiBHUAq 4cbXNpnBZEBWOCTAXxlUxcdbPxKmMSACvxHQwEQGPJCZRLp4BUEoYjwAGxro1SdAgPhleBUC AhQYFAEVWgfHVc4keIVpat0QnXZdmWJeIno8OUldXSCJnJKJwCFTHWxY2c87BwA1SQEeauEl ADgsCcAjDZTYkgFiBhVSDSlKaYcD09mon3467pmfY8x0hECeBzQwAAMEXOKaDQcI8EBHAzyw qBchAAA7 --------------050007050004070007020800-- --------------070001090703090002060300--

1 0

Re: (ITS#7218) Not deleted in Syncrepl
by hyc＠symas.com 28 Mar '12

28 Mar '12

s_hira(a)nifty.com wrote: > Full_Name: HIRABAYASHI Satoshi > Version: v2.4.30 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (221.250.200.130) > > > I confirmed the problem that was not deleted in syncrepl of V2.4.30. Thanks for the report, fixed now in git master. > > The provider operates it in "syncprov-sessionlog 100". > After I delete 150 in a provider, and going syncrepl > Only 100 cases are deleted in the consumer side. > > After examining it, the following parts seem to have a problem. > > servers/slapd/overlays/syncprov.c:2638 > if ( sl->sl_num> 0 ) { > int i; > for ( i=0; i<sl->sl_numcsns; i++ ) { > /* SID not present == new enough */ > if ( minsid< sl->sl_sids[i] ) { > do_play = 1; > break; > } > /* SID present and new enough */ > if ( minsid == sl->sl_sids[i] > && ber_bvcmp(&mincsn,&sl->sl_mincsn[i] )>= 0 ) { > do_play = 1; > break; > } > } > /* SID not present == new enough */ > if ( i == sl->sl_numcsns ) > do_play = 1; > } > if ( do_play ) { > do_present = 0; > /* mutex is unlocked in playlog */ > syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids ); > } else { > ldap_pvt_thread_mutex_unlock(&sl->sl_mutex ); > } > > Then, it corrected as follows. > === > - if ( minsid == sl->sl_sids[i] > -&& ber_bvcmp(&mincsn,&sl->sl_mincsn[i] )>= 0 ) { > + if ( minsid == sl->sl_sids[i] ) { > + if ( ber_bvcmp(&mincsn,&sl->sl_mincsn[i] )>= 0 ) { > do_play = 1; > + } > break; > } > > Is this correction wrong? > > > HIRABAYASHI Satoshi > s_hira(a)nifty.com > > -- -- 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#7218) Not deleted in Syncrepl
by s_hira＠nifty.com 28 Mar '12

28 Mar '12

Full_Name: HIRABAYASHI Satoshi Version: v2.4.30 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (221.250.200.130) I confirmed the problem that was not deleted in syncrepl of V2.4.30. The provider operates it in "syncprov-sessionlog 100". After I delete 150 in a provider, and going syncrepl Only 100 cases are deleted in the consumer side. After examining it, the following parts seem to have a problem. servers/slapd/overlays/syncprov.c:2638 if ( sl->sl_num > 0 ) { int i; for ( i=0; i<sl->sl_numcsns; i++ ) { /* SID not present == new enough */ if ( minsid < sl->sl_sids[i] ) { do_play = 1; break; } /* SID present and new enough */ if ( minsid == sl->sl_sids[i] && ber_bvcmp( &mincsn, &sl->sl_mincsn[i] ) >= 0 ) { do_play = 1; break; } } /* SID not present == new enough */ if ( i == sl->sl_numcsns ) do_play = 1; } if ( do_play ) { do_present = 0; /* mutex is unlocked in playlog */ syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids ); } else { ldap_pvt_thread_mutex_unlock( &sl->sl_mutex ); } Then, it corrected as follows. === - if ( minsid == sl->sl_sids[i] - && ber_bvcmp( &mincsn, &sl->sl_mincsn[i] ) >= 0 ) { + if ( minsid == sl->sl_sids[i] ) { + if ( ber_bvcmp( &mincsn, &sl->sl_mincsn[i] ) >= 0 ) { do_play = 1; + } break; } Is this correction wrong? HIRABAYASHI Satoshi s_hira(a)nifty.com

1 0

Re: (ITS#7182) back-ldap monitoring improvements
by hyc＠symas.com 27 Mar '12

27 Mar '12

ondrej.kuznik(a)acision.com wrote: > Full_Name: Ondrej Kuznik > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120228-back-ldap-monitoring… > Submission from: (NULL) (62.168.56.1) > > > I have prepared some patches to back-ldap (and one to back-monitor) that expose > operation and connection monitoring information from a running back-ldap > database and I would like to see this or similar functionality included in the > OpenLDAP codebase. > > The url above contains a patchset against HEAD for review. > > The following things are yet to be resolved: > - there is no monitoring of completed operations yet, only operations initiated > against the remote database(s). > - the binds performed by the ldap_back_default_rebind function are not counted > - slapo-chain has not been tested yet > - test suite integration: back-ldap looks excluded from the test suite > - better connection handling (connections should have stable identifiers) I have pushed patches 1-3 to git master. patch 4 seems to require additional work. -- -- 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#6987) cn=config renumbers indexes on startup without modrdn-ing them
by hyc＠symas.com 27 Mar '12

27 Mar '12

Ondrej Kuznik wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/12/2012 12:27 PM, hyc(a)symas.com wrote: >> This ITS still appears to me to be invalid. bconfig treats all siblings *of >> the same type* as a single ordering. Your demonstration code is claiming your >> entries are all of the same type, even though they aren't. I.e., all entries >> in cn=config of a given type have only one distinguished naming attribute. You >> have used olcTestAttrOne and olcTestAttrTwo for the same type, so cn=config >> doesn't distinguish them in its sort order. > > I tried implementing a check for Cft_Misc that considers only siblings > of the same distinguished naming attribute: > ftp://ftp.openldap.org/incoming/ondrej-kuznik-20120309-ITS-6987.patch I've committed a cleaned up version of this patch to git master. Thanks for the patch. > > During an IRC conversation in January you suggested not renumbering > Cft_Misc entries at all, like the patch below. Such a change might > however affect other overlays since captive backends seem to be regarded > as Cft_Misc entries too, based on my tests with it: > ftp://ftp.openldap.org/incoming/ondrej-kuznik-20120309-ITS-6987-no-renumber… Decided we don't know enough about how Cft_misc entries will be used in the future to take this approach. > > The attached file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Acision. Acision has not assigned rights > and/or interest in this work to any party. I, Ondrej Kuznik am > authorized by Acision, my employer, to release this work under the > following terms. > > The attached modifications to OpenLDAP Software are subject to the > following notice: > Copyright 2012 Acision > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. > > - -- > Ondrej Kuznik > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9aHu0ACgkQ9GWxeeH+cXvpGgCeN5iMhB6iyq3MjFJVx45AWmX+ > uykAnjidKeewlH1EhlBBr+BTFgxZNodM > =+FEP > -----END PGP SIGNATURE----- > > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding. > > > -- -- 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#7215) Configuration Bug of index_substr_if_{max, min}len
by h.b.furuseth＠usit.uio.no 26 Mar '12

26 Mar '12

On Mon, 26 Mar 2012 19:16:11 GMT, tixu(a)cs.ucsd.edu wrote: > just set the following two lines in the beginning of the slapd.conf, > > index_substr_if_maxlen 100 > index_substr_if_minlen 5 > > slapd starts without a warning and can serve requests. That's not the example you gave in last message. The error message should be more helpful: If you want minlen that big, you have to set maxlen first. Except, this can still break cn=config replication: Either setting this configuration or reverting to the old one will not work. I don't know if cn=config supports delaying this check until the entire new entry is available, and reverting if the check fails? -- Hallvard

1 0

Re: (ITS#7215) Configuration Bug of index_substr_if_{max, min}len
by tixu＠cs.ucsd.edu 26 Mar '12

26 Mar '12

--000325575576f2e15a04bc2a31c8 Content-Type: text/plain; charset=ISO-8859-1 hmmm... I have to say I can replay it every time. just set the following two lines in the beginning of the slapd.conf, index_substr_if_maxlen 100 index_substr_if_minlen 5 slapd starts without a warning and can serve requests. T On Mon, Mar 26, 2012 at 2:43 AM, Howard Chu <hyc(a)symas.com> wrote: > tixu(a)cs.ucsd.edu wrote: > >> Full_Name: Tianyin Xu >> Version: 2.4.30 >> OS: Ubuntu Linux 10.04 >> URL: ftp://ftp.openldap.org/**incoming/<ftp://ftp.openldap.org/incoming/> >> Submission from: (NULL) (128.54.167.68) >> >> >> 1. Symptom: >> >> In the main configuration file of OpenLDAP (slapd.conf), set the following >> configuration: >> >> index_substr_if_minlen 100 >> index_substr_if_maxlen 5 >> >> Then, everything is fine. The system behaves as expectation. However, if >> reverse >> the order of the two configuration line as follows: >> >> index_substr_if_maxlen 5 >> index_substr_if_minlen 100 >> >> Then, the system refused to start, with the following misleading message: >> >> Mar 25 21:29:18 tianyin-desktop slapd[12700]: >> /home/tianyin/openldap-2.4.30/**etc/openldap/slapd.conf: line 1: >> <index_substr_if_minlen> invalid value (5) >> > > Unable to reproduce this symptom. In both cases I get > > testrun/slapd.1.conf: line 31: <index_substr_if_minlen> invalid value (100) > > Closing this ITS. > > >> ------------------------------**--------------------------- >> >> 2. Root cause in terms of code snippet >> >> (1) servers/slapd/slap.h >> >> #define SLAP_INDEX_SUBSTR_IF_MINLEN_**DEFAULT 2 >> #define SLAP_INDEX_SUBSTR_IF_MAXLEN_**DEFAULT 4 >> >> (2) servers/slapd/schema_init.c >> >> unsigned int index_substr_if_minlen = SLAP_INDEX_SUBSTR_IF_MINLEN_** >> DEFAULT; >> unsigned int index_substr_if_maxlen = SLAP_INDEX_SUBSTR_IF_MAXLEN_** >> DEFAULT; >> >> (3) servers/slapd/bconfig.c >> >> case CFG_SSTR_IF_MAX: >> if (c->value_uint< index_substr_if_minlen) { >> snprintf(c->cr_msg, sizeof(c->cr_msg), "<%s> invalid value", >> c->argv[0]); >> Debug(LDAP_DEBUG_ANY, "%s: %s (%d)\n", c->log, c->cr_msg, >> c->value_int); >> return(1); >> } >> index_substr_if_maxlen = c->value_uint; >> break; >> >> case CFG_SSTR_IF_MIN: >> if (c->value_uint> index_substr_if_maxlen) { >> snprintf(c->cr_msg, sizeof( c->cr_msg ), "<%s> invalid value", >> c->argv[0]); >> Debug(LDAP_DEBUG_ANY, "%s: %s (%d)\n", c->log, c->cr_msg, >> c->value_int >> ); >> return(1); >> } >> index_substr_if_minlen = c->value_uint; >> break; >> >> (4) backtrace >> >> #0 config_generic (c=0x915760) at bconfig.c:1996 >> #1 0x0000000000433a00 in config_set_vals (Conf=0x8146c0, c=0x915760) at >> config.c:345 >> #2 0x0000000000433f5f in config_add_vals (Conf=0x8146c0, c=0x915760) at >> config.c:418 >> #3 0x00000000004351b3 in read_config_file (fname=0x5a0a98 >> "/home/tianyin/openldap-2.4.**30/etc/openldap/slapd.conf", depth=0, >> cf=0x0, >> cft=0x8140c0) at config.c:783 >> #4 0x000000000042846b in read_config (fname=0x0, dir=0x0) at >> bconfig.c:4213 >> #5 0x000000000041c217 in main (argc=1, argv=0x7fffffffe2f8) at main.c:792 >> >> ------------------------------**--------------------------- >> >> It's quite clear that the order matters, and this should be a bug related >> to >> configuration. >> >> Thanks, >> Tianyin >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> > -- Tianyin XU, http://cseweb.ucsd.edu/~tixu/ --000325575576f2e15a04bc2a31c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hmmm... I have to say I can replay it every time.<div><br></div><div>just s= et the following two lines in the beginning of the slapd.conf,</div><div><b= r></div><div><div>index_substr_if_maxlen 100</div><div>index_substr_if_minl= en 5</div> <div><br></div><div>slapd starts without a warning and can serve requests.<= /div><div><br></div><div>T</div> <div><br></div><br><div class=3D"gmail_quote">On Mon, Mar 26, 2012 at 2:43 = AM, Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" targe= t=3D"_blank">hyc(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"> <div><a href=3D"mailto:tixu@cs.ucsd.edu" target=3D"_blank">tixu(a)cs.ucsd.edu= </a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Tianyin Xu<br> Version: 2.4.30<br> OS: Ubuntu Linux 10.04<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/<u></u>incoming/</a><br> Submission from: (NULL) (128.54.167.68)<br> <br> <br> 1. Symptom:<br> <br> In the main configuration file of OpenLDAP (slapd.conf), set the following<= br> configuration:<br> <br> index_substr_if_minlen 100<br> index_substr_if_maxlen 5<br> <br> Then, everything is fine. The system behaves as expectation. However, if re= verse<br> the order of the two configuration line as follows:<br> <br> index_substr_if_maxlen 5<br> index_substr_if_minlen 100<br> <br> Then, the system refused to start, with the following misleading message:<b= r> <br> Mar 25 21:29:18 tianyin-desktop slapd[12700]:<br> /home/tianyin/openldap-2.4.30/<u></u>etc/openldap/slapd.conf: line 1:<br> <index_substr_if_minlen> =A0invalid value (5)<br> </blockquote> <br></div> Unable to reproduce this symptom. In both cases I get<br> <br> testrun/slapd.1.conf: line 31: <index_substr_if_minlen> invalid value= (100)<br> <br> Closing this ITS.<div><div><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> ------------------------------<u></u>---------------------------<br> <br> 2. Root cause in terms of code snippet<br> <br> (1) servers/slapd/slap.h<br> <br> #define SLAP_INDEX_SUBSTR_IF_MINLEN_<u></u>DEFAULT =A0 =A0 2<br> #define SLAP_INDEX_SUBSTR_IF_MAXLEN_<u></u>DEFAULT =A0 =A0 4<br> <br> (2) servers/slapd/schema_init.c<br> <br> unsigned int index_substr_if_minlen =3D SLAP_INDEX_SUBSTR_IF_MINLEN_<u></u>= DEFAULT;<br> unsigned int index_substr_if_maxlen =3D SLAP_INDEX_SUBSTR_IF_MAXLEN_<u></u>= DEFAULT;<br> <br> (3) servers/slapd/bconfig.c<br> <br> case CFG_SSTR_IF_MAX:<br> =A0 =A0 if (c->value_uint< =A0index_substr_if_minlen) {<br> =A0 =A0 =A0 =A0 snprintf(c->cr_msg, sizeof(c->cr_msg), "<%s&= gt; =A0invalid value",<br> c->argv[0]);<br> =A0 =A0 =A0 =A0 Debug(LDAP_DEBUG_ANY, "%s: %s (%d)\n", c->log= , c->cr_msg,<br> c->value_int);<br> =A0 =A0 =A0 =A0 return(1);<br> =A0 =A0 }<br> =A0 =A0 index_substr_if_maxlen =3D c->value_uint;<br> =A0 =A0 break;<br> <br> case CFG_SSTR_IF_MIN:<br> =A0 =A0 if (c->value_uint> =A0index_substr_if_maxlen) {<br> =A0 =A0 =A0 =A0 snprintf(c->cr_msg, sizeof( c->cr_msg ), "<%= s> =A0invalid value",<br> c->argv[0]);<br> =A0 =A0 =A0 =A0 Debug(LDAP_DEBUG_ANY, "%s: %s (%d)\n", c->log= , c->cr_msg, c->value_int<br> );<br> =A0 =A0 =A0 =A0 return(1);<br> =A0 =A0 }<br> =A0 =A0 index_substr_if_minlen =3D c->value_uint;<br> =A0 =A0 break;<br> <br> (4) backtrace<br> <br> #0 =A0config_generic (c=3D0x915760) at bconfig.c:1996<br> #1 =A00x0000000000433a00 in config_set_vals (Conf=3D0x8146c0, c=3D0x915760)= at<br> config.c:345<br> #2 =A00x0000000000433f5f in config_add_vals (Conf=3D0x8146c0, c=3D0x915760)= at<br> config.c:418<br> #3 =A00x00000000004351b3 in read_config_file (fname=3D0x5a0a98<br> "/home/tianyin/openldap-2.4.<u></u>30/etc/openldap/slapd.conf", d= epth=3D0, cf=3D0x0,<br> cft=3D0x8140c0) at config.c:783<br> #4 =A00x000000000042846b in read_config (fname=3D0x0, dir=3D0x0) at bconfig= .c:4213<br> #5 =A00x000000000041c217 in main (argc=3D1, argv=3D0x7fffffffe2f8) at main.= c:792<br> <br> ------------------------------<u></u>---------------------------<br> <br> It's quite clear that the order matters, and this should be a bug relat= ed to<br> configuration.<br> <br> Thanks,<br> Tianyin<br> <br> <br> </blockquote> <br> <br></div></div><span><font color=3D"#888888"> -- <br> =A0-- Howard Chu<br> =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a><br> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a><br> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r><span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;= text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:no= rmal;border-collapse:separate;text-transform:none;font-size:medium;white-sp= ace:normal;font-family:'Times New Roman';word-spacing:0px"><span st= yle=3D"color:rgb(102,102,102);font-family:arial;font-size:small">Tianyin XU= ,<br> <a href=3D"http://cseweb.ucsd.edu/%7Etixu/" target=3D"_blank">http://cseweb= .ucsd.edu/~tixu/</a></span></span><br> </div> --000325575576f2e15a04bc2a31c8--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs