openldap-bugs February 2012

openldap-bugs@openldap.org

33 participants
146 discussions

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

02 Feb '12

llg(a)portaildulibre.fr wrote: > Le 02/02/2012 20:32, hyc(a)symas.com a écrit : >> 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 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. >> That is obviously the wrong approach. Since these backends communicate using >> LDIF, binary values should be base64 encoded according to the LDIF rules. > 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 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. >> Thanks for the patch, but we can't merge it since the provided solution 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/

1 0

Re: (ITS#7149) Back-perl, Back-shell and Binary Data
by llg＠portaildulibre.fr 02 Feb '12

02 Feb '12

Le 02/02/2012 20:32, hyc(a)symas.com a écrit : > 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 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. > That is obviously the wrong approach. Since these backends communicate using > LDIF, binary values should be base64 encoded according to the LDIF rules. 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. Llg > > Thanks for the patch, but we can't merge it since the provided solution is wrong. >

1 0

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

02 Feb '12

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 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. That is obviously the wrong approach. Since these backends communicate using LDIF, binary values should be base64 encoded according to the LDIF rules. Thanks for the patch, but we can't merge it since the provided solution 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/

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by michael＠stroeder.com 02 Feb '12

02 Feb '12

dcoutadeur(a)linagora.com wrote: > I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git > version) Which exact git version? Did you build RE24 from git already containing the fix for ITS#7113 (dup of ITS#6928)? Ciao, Michael.

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by quanah＠zimbra.com 02 Feb '12

02 Feb '12

--On Thursday, February 02, 2012 4:58 PM +0000 dcoutadeur(a)linagora.com wrote: > Full_Name: dcoutadeur > Version: 2.4.28 > OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (109.197.176.10) > Please rebuild with debugging symbols (CFLAGS=-g) and update with a usable stack trace. Thank you. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by dcoutadeur＠linagora.com 02 Feb '12

02 Feb '12

Full_Name: dcoutadeur Version: 2.4.28 OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.197.176.10) Hi everybody, I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git version) slapd is shutting down with no message in the logs when I try to do a load benchmark with a soft in C. The test consists in 20 threads doing 100 times these operations in the order : - 1 entry add - 1 modification on this entry - 1 deletion on this entry Of course, some operations ends up with ldap errors, because the entry does not exist, and so on... During the load testing, Openldap is reacting as expected. If I stop the test while it runs, then the bug occurs (nearly systematically) You can check my configuration and the stacktrace here. Thank you in advance for helping. # ---------------------------------------------------------------------------- # Global section # ---------------------------------------------------------------------------- sizelimit 15000 allow bind_v2 password-hash {SSHA} threads 8 loglevel 256 serverID 2 include /opt/openldap/etc/openldap/inc_shemas/slapd-schemas.conf pidfile /opt/openldap/var/run/slapd.pid argsfile /opt/openldap/var/run/slapd.args # ACLs definition (cutted here) ####################################################################### # SSL definitions ####################################################################### # Definition of cert files # --------------------------------- TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /usr/local/openldap/etc/certs/ca.cert TLSCertificateFile /usr/local/openldap/etc/certs/ldap-master-2.cert TLSCertificateKeyFile /usr/local/openldap/etc/certs/ldap-master-2.key TLSVerifyClient never ####################################################################### # BDB database definitions ####################################################################### database monitor ####################################################################### # suffix dc=example,dc=com # -------------------- ####################################################################### database bdb directory /opt/openldap/var/openldap-data # some indexes # ---------------------------------------------------------------------------- # root suffix # ---------------------------------------------------------------------------- suffix "dc=example,dc=com" checkpoint 512 10 # ---------------------------------------------------------------------------- # cache settings # ---------------------------------------------------------------------------- cachesize 60000 dncachesize 60000 idlcachesize 60000 cachefree 100 rootdn "cn=Manager,dc=example,dc=com" rootpw secret # Password policy : hash the clear passwords overlay ppolicy ppolicy_hash_cleartext # ---------------------------------------------------------------------------- # REPLICATION definitions # ---------------------------------------------------------------------------- ####################################################################### # I am a master (provider) # ------------------------------------------ overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # syncrepl directive (consummer infos) # ------------------------------------------ syncrepl rid=001 provider=ldap://ldap-master-1.example.com bindmethod=simple binddn="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on # ---------------------------------------------------------------------------- # limits # ---------------------------------------------------------------------------- limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited ####################################################################### # suffix o=edition # ---------------- ####################################################################### database bdb directory /opt/openldap/var/openldap-data-edition # some indexes # ---------------------------------------------------------------------------- # root suffix # ---------------------------------------------------------------------------- suffix "o=edition" checkpoint 512 10 # ---------------------------------------------------------------------------- # cache settings # ---------------------------------------------------------------------------- cachesize 50000 dncachesize 50000 idlcachesize 50000 cachefree 100 # ---------------------------------------------------------------------------- # rootdn # ---------------------------------------------------------------------------- # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootdn "cn=Manager,o=edition" rootpw secret # Password policy : hash the clear passwords overlay ppolicy ppolicy_hash_cleartext ####################################################################### # REPLICATION definitions ####################################################################### # I am a master (provider) # ------------------------------------------ overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # syncrepl directive (consummer infos) # ------------------------------------------ syncrepl rid=002 provider=ldap://vspar-ldap-master-1.example.com bindmethod=simple binddn="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" credentials=secret searchbase="o=edition" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on # ---------------------------------------------------------------------------- # Limits for current BDB # ---------------------------------------------------------------------------- limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited ############################################################### ######################## STACKTRACE ########################### ############################################################### (gdb) thread apply all bt Thread 10 (Thread 32314): #0 0x006b3402 in ?? () #1 0x00822a77 in ?? () #2 0xbffb3a5c in ?? () #3 0x00822930 in ?? () #4 0x9c5b2d90 in ?? () #5 0x00000000 in ?? () Thread 9 (Thread 32325): #0 0x006b3402 in ?? () #1 0x00203ae6 in ?? () #2 0x00000000 in ?? () Thread 8 (Thread 32326): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8ccb5258 in ?? () #5 0x8ddb7cd8 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8ddb7ca8) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 7 (Thread 32327): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () ---Type <return> to continue, or q <return> to quit--- #3 0x006152a9 in ?? () #4 0x8cbb4258 in ?? () #5 0x8d9b7e68 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8d9b7e38) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 6 (Thread 32328): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8c9b2258 in ?? () #5 0x8d5b6e68 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8d5b6e38) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 5 (Thread 32329): #0 0x0019673c in ?? () #1 0x8d1b4fed in ?? () #2 0x089bfbd0 in ?? () #3 0x00000018 in ?? () #4 0x00000009 in ?? () #5 0x081b2684 in ?? () #6 0x0000000a in ?? () #7 0x8d1b4fed in ?? () #8 0x00285ff4 in ?? () #9 0x081b267a in ?? () #10 0x0000000a in ?? () ---Type <return> to continue, or q <return> to quit--- #11 0x8d1b4e98 in ?? () #12 0x0016d391 in ?? () #13 0x8d1b4ebc in ?? () #14 0x081b267a in ?? () #15 0x0000000a in ?? () #16 0x0012eed5 in ?? () #17 0x00000000 in ?? () Thread 4 (Thread 32392): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8b6ab258 in ?? () #5 0x8c5afc98 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8c5afc68) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 3 (Thread 32393): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8b7ac258 in ?? () #5 0x8c1adcd8 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8c1adca8) at syncprov.c:2112 Backtrace stopped: frame did not save the PC ---Type <return> to continue, or q <return> to quit--- Thread 2 (Thread 32394): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8b5aa258 in ?? () #5 0x8bcace68 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8bcace38) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 1 (Thread 32391): #0 0x0818d9c2 in syncprov_op_mod (op=0x89b2fe0, rs=0x8c9b1108) at syncprov.c:2118 #1 0x080dff34 in overlay_op_walk (op=0x89b2fe0, rs=0x8c9b1108, which=op_add, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #2 0x080e049a in over_op_func (op=0x89b2fe0, rs=0x8c9b1108, which=op_add) at backover.c:723 #3 0x0807eeb9 in fe_op_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:334 #4 0x0807f7a3 in do_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:194 #5 0x0807759d in connection_operation (ctx=0x8c9b11e8, arg_v=0x89b2fe0) at connection.c:1138 #6 0x08077f6d in connection_read_thread (ctx=0x8c9b11e8, argv=0x2f) at connection.c:1274 #7 0x006145e4 in ?? () #8 0x8c9b11e8 in ?? () #9 0x0000002f in ?? () #10 0x00000000 in ?? ()

1 0

(ITS#7149) Back-perl, Back-shell and Binary Data
by jiashun.qian＠atos.net 02 Feb '12

02 Feb '12

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 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. Same problem in servers/slapd/back-shell/modify.c : --- servers/slapd/back-shell/modify.c fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, mod->sm_values[i].bv_val /* binary! */ ); --- To fix this, uses a loop on mod->sm_values[i].bv_len to get all data. *** openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11-25 19:52:29.000000000 +0100 --- openldap-2.4.28/servers/slapd/back-perl/modify.c 2012-02-02 14:15:37.823838779 +0100 *************** *** 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. */ --- 61,67 ---- mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! mXPUSHp(mods->sm_values[i].bv_val, mods->sm_values[i].bv_len); } /* Fix delete attrib without value. */ *** openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11-25 19:52:29.000000000 +0100 --- openldap-2.4.28/servers/slapd/back-shell/modify.c 2012-02-02 14:26:40.609848244 +0100 *************** *** 49,55 **** Modifications *ml = op->orm_modlist; Entry e; FILE *rfp, *wfp; ! int i; if ( si->si_modify == NULL ) { send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM, --- 49,56 ---- Modifications *ml = op->orm_modlist; Entry e; FILE *rfp, *wfp; ! int i,j; ! unsigned char *ptr; 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! */ ); } } --- 106,118 ---- if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! fprintf( wfp, "%s: ", mod->sm_desc->ad_cname.bv_val ); ! ptr = mod->sm_values[i].bv_val; ! for(j=0; j < mod->sm_values[i].bv_len; j++) ! { ! fprintf( wfp, "%c", *ptr++ ); ! } ! fprintf( wfp, "\n" ); } } Special thanks to : Laurent Le Grandois, Cedric Pellerin, Phillipe Prados for the fix

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by hyc＠symas.com 02 Feb '12

02 Feb '12

Sven Hartge wrote: > On 02.02.2012 11:25, Howard Chu wrote: >> Sven Hartge wrote: >>> Um 14:47 Uhr am 01.02.12 schrieb Quanah Gibson-Mount: >>> >>>> Could you *please* try the RE24 checkout from GIT rather than 2.4.28? >>>> Thanks. >>>> That is substantially more useful than patching 2.4.28. >>> >>> I'm sorry to report: still segfaults, backtrace is attached. >> >> This patch should take care of that crash. > > Yes, works. Thank you very much! Thanks for the confirmation, committed to master. -- -- 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#7146) mdb_info.mi_adxs[] overflow
by h.b.furuseth＠usit.uio.no 02 Feb '12

02 Feb '12

Full_Name: Hallvard B Furuseth Version: master: 2e9f1f93c8acf028fffeec3fc8bafd1a19b719b7 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard mdb_info.mi_adxs[] should be a hash table. It is indexed by AttributeDescription.ad_index, which can be > MDB_MAXADS. Currently back-mdb dumps core with 'attributeoptions foo-' in slapd.conf when ldapadding an ldif which does dn: l=e$i,o=adxs objectClass: locality st;foo-$i: bar # optionally: dn: l=e$i,o=adxs changetype: delete for i = 0...66000.

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by quanah＠zimbra.com 01 Feb '12

01 Feb '12

--On Wednesday, February 01, 2012 10:27 PM +0000 sven(a)svenhartge.de wrote: > Um 01:00 Uhr am 01.02.12 schrieb Howard Chu: >> Sven Hartge wrote: >>> On 02/01/12 05:56, Howard Chu wrote: >>>> sven(a)svenhartge.de wrote: > >>> > > I get a very good backtrace, but since this backtrace contains >>> > > internal information I am a bit hesitant to attach this backtrace >>> > > to a public bug-report. >>> > >>> > The backtrace you sent shows the crash at a line of code which was >>> > already patched in RE24 due to ITS#7132. I believe this bug is already >>> > fixed. >>> >>> This is good news. Do you have any commit ID so I can try to backport >>> this fix to the version currently in Debian Squeeze? >> >> commit 42faa8393e6cd41a837b526777110b892541773a > > This simple patch applies flawless on 2.4.23 but still segfaults. Will > try on top of 2.4.28 tomorrow, backtraces will follow then, after I > verified my findings. > > > (Reason for trying this on top of 2.4.23 is because this is the version > in Debian Squeeze and I want to provide the DDs with a fix for Squeeze. > I fully understand that is not supported by OpenLDAP.) > Could you *please* try the RE24 checkout from GIT rather than 2.4.28? Thanks. That is substantially more useful than patching 2.4.28. You can check out an tarball of current RE24 with: git archive --format=tar --remote=git.openldap.org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4 > openldap-2.4.29.tar Or via the web with: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2012