- openldap-bugs - openldap.org

Re: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4, 24
by h.b.furuseth＠usit.uio.no 14 Mar '11

14 Mar '11

dvladi(a)websense.com writes: > You are right, ldap_int_thread_mutex_(X) functions were introduced in > 2.3.8 on 10/06/2005. > > But there is NO declaration or function definition anywhere in the code. Fixed in HEAD to ldap_pvt_thread_mutex_init() after an overeager namespace cleanup. (I had confused it with some libldap_r debug stuff.) The other ldap_int_* stuff looks OK. -- Hallvard

1 0

(ITS#6863) possible null pointer dereference in NSS
by jvcelak＠redhat.com 14 Mar '11

14 Mar '11

Full_Name: Jan Vcelak Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/jan-vcelak-nss-null-pointer-dereference-110… Submission from: (NULL) (209.132.186.34) Hello. Recent NSS patch, which adds full non-blocking semantics (ITS #6714), introduced possible NULL pointer dereference by mistake. This patch fixes the problem. Jan

1 0

(ITS#6862) Patch - Mozilla NSS - redux: disable pkcs11 fork checking for the software token
by rmeggins＠redhat.com 10 Mar '11

10 Mar '11

Full_Name: Rich Megginson Version: 2.4.24 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.24-use-strdup-for-nofork-envva… Submission from: (NULL) (76.113.111.209) There was still a problem with the fix for http://www.openldap.org/its/index.cgi?findid=6811 Under certain conditions, and with certain shells, the PR_SetEnv with the constant string was causing free() assertion failures in unrelated software. # su - foo free(0x173bd2) below bottom of memory. (memtop = 0x9898800 membot = 0x973e000) # gdb /bin/tcsh coredump (gdb) bt #0 0x00ed9416 in __kernel_vsyscall () #1 0x006e02f1 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x006e1d5e in abort () at abort.c:92 #3 0x08084e6a in free (cp=0x8f2bd2) at tc.alloc.c:313 #4 0x08063d83 in blkfree (av0=0x9e7d988) at sh.misc.c:158 #5 0x0805af6f in tsetenv (name=0x80a3420 L"GROUP", val=0x9e32608 L"valid_group") at sh.func.c:1725 #6 0x0804d910 in main (argc=<value optimized out>, argv=0xbfa7e4f4) at sh.c:561 Using PR_SetEnv with a strdup()ed string solved the problem. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6860) slapadd accepts duplicate objectclasses
by masarati＠aero.polimi.it 10 Mar '11

10 Mar '11

hyc(a)symas.com wrote: > dieter(a)dkluenter.de wrote: >> Full_Name: Dieter Klünter >> Version: 2.4.24 >> OS: SLES11_x64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.18.17) >> >> >> A ldif generator created out of a total of 100,000 entries 10,000 entries with >> duplicate objectclasses i.e. >> >> dn: cn=Michelina Al-Basi,ou=Accounting,ou=bremen,dc=dkluenter,dc=de >> objectClass: top >> objectClass: person >> objectClass: organizationalPerson >> objectClass: inetOrgPerson >> objectClass: top >> objectClass: person >> objectClass: organizationalPerson >> objectClass: inetOrgPerson >> cn: Al-BasiM >> sn: Al-Basi >> >> This ldif has been loaded by slapadd without any warnings. The only parameter >> applied where -l and -f. > > This is normal. slapadd doesn't do validation, you are expected to feed it > valid output from slapcat. This documented behavior has not changed in a decade. Let me add that in recent releases you can specify -o value-check=yes to enforce value checking (incurring in the related penalty). This would have revealed the error. p.

1 0

(ITS#6861) slapd and syncrepl performance problem
by jeff_wheeler67＠comcast.net 10 Mar '11

10 Mar '11

Full_Name: Jeff Wheeler Version: 2.4.20 OS: RHEL4.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.103.136.179) Under ldapsearch/modify load of approximately 160 simultaneous sessions towards the First Master only, after several hours replication falls behind and searches and modifies that previously were <1 second now take 10 seconds+. We see also these messages continually every 5 seconds or so: Mar 10 04:02:05 auvhen2be01 slapd[29178]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Mar 10 04:02:05 auvhen2be01 slapd[29178]: conn=2249 op=13995: attribute "entryCSN" index add failure LDAP is configured in 2-way multi-master mirrormode on 2 Quad core HP blades with 72GB RAM each. Cache size set to 10GB, id2entry=18GB. The replication agreements are as such: olcSyncrepl: {0}rid=2 provider=ldap://auvhen4be05-traffic.vm.vodafone.net.au b indmethod=simple timeout=0 network-timeout=0 binddn="cn=Directory Manager,o=h 3gau" credentials="admin123" starttls=no filter="(objectclass=*)" searchbase= "o=h3gau" scope=sub schemachecking=off type=refreshAndPersist retry="60 +" .. olcOverlay: {0}syncprov olcSpCheckpoint: 100 600 .. Eventually, the syncrepl connection goes to TIME_WAIT state and replications stop. Restarting slapd does not fix and we have to reload from backup. We tuned the following and no longer does slapd repl connection go to TIME_WAIT, however it still falls hours behind on updates and performs slowly as before. Cache size set to 20GB, olcDbIDLcacheSize: 20000000000, olcThreads: 32 Restarting slapd results in the repl connection binding, searching, but then unbinds immediately: Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 fd=19 ACCEPT from IP=10.176.77.23:50798 (IP=10.176.77.47:389) Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=0 BIND dn="cn=directory manager,o=h3gau" method=128 Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=0 BIND dn="cn=directory manager,o=h3gau" mech=SIMPLE ssf=0 Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=0 RESULT tag=97 err=0 text= Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=1 SRCH base="o=h3gau" scope=2 deref=0 filter="(objectClass=*)" Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=1 SRCH attr=* + Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=2 UNBIND Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 fd=19 closed

1 0

Re: (ITS#6860) slapadd accepts duplicate objectclasses
by hyc＠symas.com 10 Mar '11

10 Mar '11

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Klünter > Version: 2.4.24 > OS: SLES11_x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.18.17) > > > A ldif generator created out of a total of 100,000 entries 10,000 entries with > duplicate objectclasses i.e. > > dn: cn=Michelina Al-Basi,ou=Accounting,ou=bremen,dc=dkluenter,dc=de > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > cn: Al-BasiM > sn: Al-Basi > > This ldif has been loaded by slapadd without any warnings. The only parameter > applied where -l and -f. This is normal. slapadd doesn't do validation, you are expected to feed it valid output from slapcat. This documented behavior has not changed in a decade. Closing this ITS. -- -- 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#6860) slapadd accepts duplicate objectclasses
by dieter＠dkluenter.de 10 Mar '11

10 Mar '11

Full_Name: Dieter Klünter Version: 2.4.24 OS: SLES11_x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.18.17) A ldif generator created out of a total of 100,000 entries 10,000 entries with duplicate objectclasses i.e. dn: cn=Michelina Al-Basi,ou=Accounting,ou=bremen,dc=dkluenter,dc=de objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Al-BasiM sn: Al-Basi This ldif has been loaded by slapadd without any warnings. The only parameter applied where -l and -f. -Dieter

1 0

Re: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4, 24
by dvladi＠websense.com 09 Mar '11

09 Mar '11

--_000_36C3E4EA3ECF49F68EBD3A7AC0A7D60Dwebsensecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You are right, ldap_int_thread_mutex_(X) functions were introduced in 2.3.8= on 10/06/2005. But there is NO declaration or function definition anywhere in the code. What was changed is 2.4.24 is ldap_int_initialize_global_options function. A call to LDAP_PVT_MUTEX_FIRSTCREATE(gopts->ldo_mutex) was added. That macro (With defined HAVE_NT_THREADS) resolves to ldap_int_thread_mutex= _init. Since that function does not exist my linker reports an error. Here is what's going on LDAP_PVT_MUTEX_FIRSTCREATE is defined in include/ldap_pvt_thread.h as LDAP_= DEBUG_MUTEX_FIRSTCREATE (if LDAP_PVT_THREAD_H_DONE is not defined and LDAP_= THREAD_DEBUG_WRAP is defined) or LDAP_INT_MUTEX_FIRSTCREATE (if both LDAP_P= VT_THREAD_H_DONE and LDAP_THREAD_DEBUG_WRAP are defined). The last one is m= y case, I could not find any definition or information on whether or not LD= AP_PVT_THREAD_H_DONE should be defined. For HAVE_NT_THREADS LDAP_INT_MUTEX_FIRSTCREATE is resolved as (include/ldap= _int_thread.h:185) #elif defined(HAVE_NT_THREADS) /************************************* * * * thread definitions for NT threads * * * *************************************/ #include <process.h> #include <windows.h> LDAP_BEGIN_DECL typedef unsigned long ldap_int_thread_t; typedef HANDLE ldap_int_thread_mutex_t; typedef HANDLE ldap_int_thread_cond_t; typedef DWORD ldap_int_thread_key_t; #ifndef LDAP_INT_MUTEX_NULL #define LDAP_INT_MUTEX_NULL ((HANDLE)0) #define LDAP_INT_MUTEX_FIRSTCREATE(m) \ ((void) ((m) || ldap_int_thread_mutex_init(&(m)))) #endif And since there is no function ldap_int_thread_mutex_init linker fails. Sincerelly Demian Vladi ----- Reply message ----- From: "openldap-its(a)OpenLDAP.org" <openldap-its(a)OpenLDAP.org> Date: Wed, Mar 9, 2011 4:01 pm Subject: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4,24 To: "Vladi, Demian" <dvladi(a)websense.com> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#6859. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#6859) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#6859) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D6859 Please remember to retain your issue tracking number (ITS#6859) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. To report this as spam, please forward to spam(a)websense.com. Thank you. Protected by Websense Hosted Email Security -- www.websense.com=20 --_000_36C3E4EA3ECF49F68EBD3A7AC0A7D60Dwebsensecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> <style></style> </head> <body> <style>  </style> <div> You are right, ldap_int_thread_mutex_(X) functions were introduced in 2.3.8= on 10/06/2005. But there is NO declaration or function definition anywhere in the code. What was changed is 2.4.24 is ldap_int_initialize_global_options function.<= br> A call to LDAP_PVT_MUTEX_FIRSTCREATE(gopts->ldo_mutex) was added. That macro (With defined HAVE_NT_THREADS) resolves to ldap_int_thread_mutex= _init. Since that function does not exist my linker reports an error. Here is what's going on LDAP_PVT_MUTEX_FIRSTCREATE is defined in include/ldap_pvt_thread.h as LDAP_= DEBUG_MUTEX_FIRSTCREATE (if LDAP_PVT_THREAD_H_DONE is not defined and LDAP_= THREAD_DEBUG_WRAP is defined) or LDAP_INT_MUTEX_FIRSTCREATE (if both LDAP_P= VT_THREAD_H_DONE and LDAP_THREAD_DEBUG_WRAP are defined). The last one is my case, I could not find any definition or = information on whether or not LDAP_PVT_THREAD_H_DONE should be defined. For HAVE_NT_THREADS LDAP_INT_MUTEX_FIRSTCREATE is resolved as (include/ldap= _int_thread.h:185) #elif defined(HAVE_NT_THREADS) /*************************************  *           &n= bsp;           &nbsp= ;           *  * thread definitions for NT threads *  *           &n= bsp;           &nbsp= ;           *  *************************************/ #include <process.h> #include <windows.h> LDAP_BEGIN_DECL typedef unsigned long   ldap_int_thread_t; typedef HANDLE  ldap_int_thread_mutex_t; typedef HANDLE  ldap_int_thread_cond_t; typedef DWORD   ldap_int_thread_key_t; #ifndef LDAP_INT_MUTEX_NULL #define LDAP_INT_MUTEX_NULL        =      ((HANDLE)0) #define LDAP_INT_MUTEX_FIRSTCREATE(m) \             &nb= sp;   ((void) ((m) || ldap_int_thread_mutex_init(&(m)))) #endif And since there is no function ldap_int_thread_mutex_init linker fails. Sincerelly Demian Vladi <div id=3D"x_htc_header" style=3D"">----- Reply message ----- From: "openldap-its(a)OpenLDAP.org" <openldap-its(a)OpenLDAP.org&g= t; Date: Wed, Mar 9, 2011 4:01 pm Subject: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4,24<= br> To: "Vladi, Demian" <dvladi(a)websense.com> </div> </div> <div class=3D"PlainText"> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System.  Your report has been assigned the tracking number ITS#6859. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers.  They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message.  Note that any mail sent to openldap-its(a)openldap.org with (ITS#6859) in the subject will automatically be attached to the issue report.         <a href=3D"mailto:openldap-its@o= penldap.org?subject=3D(ITS#6859">mailto:openldap-its@openldap.org?subject= =3D(ITS#6859</a>) You may follow the progress of this report by loading the following URL in a web browser:     <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid= =3D6859">http://www.OpenLDAP.org/its/index.cgi?findid=3D6859</a> Please remember to retain your issue tracking number (ITS#6859) on any further messages you send to us regarding this report.  If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported.         <a href=3D"http://www.OpenLDAP.o= rg/support/">http://www.OpenLDAP.org/support/</a> -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.  To report this as spam, please forward to spam(a)websense.com.  Th= ank you. </div> Protected by Websense Hosted Email Security &#8= 212; www.websense.com </body> </html> --_000_36C3E4EA3ECF49F68EBD3A7AC0A7D60Dwebsensecom_--

1 0

Re: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4, 24
by hyc＠symas.com 09 Mar '11

09 Mar '11

dvladi(a)websense.com wrote: > Full_Name: Demian Vladi > Version: 2.4.24 > OS: Windwos > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (204.15.64.155) > > > My program that uses openLdap fails to link for me due to unresolved > ldap_int_thread_mutex_(X) functions, e.g ldap_int_thread_mutex_init. > It looks like they were introduced in 2.4.24, but there is no definition or > declaration for them :( > You're mistaken, these definitions were introduced many years ago. Long before 2.4.24. Long before 2.3 even. Sounds like you're linking incorrectly. No bug here, this ITS will be closed. For help with usage questions please post on the openldap-technical mailing list. -- -- 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#6859) ldap_int_thread_mutex_x functions introduced in 2.4,24
by dvladi＠websense.com 09 Mar '11

09 Mar '11

Full_Name: Demian Vladi Version: 2.4.24 OS: Windwos URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.15.64.155) My program that uses openLdap fails to link for me due to unresolved ldap_int_thread_mutex_(X) functions, e.g ldap_int_thread_mutex_init. It looks like they were introduced in 2.4.24, but there is no definition or declaration for them :(

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 09 Mar '11

09 Mar '11

--On March 9, 2011 9:42:18 AM -0800 Howard Chu <hyc(a)symas.com> wrote: > Quanah Gibson-Mount wrote: >> >> >> --On March 4, 2011 11:14:46 PM +0000 dhawes(a)vt.edu wrote: >>> Tested, and working. Thanks for the fix. >> >> We're still seeing this happen sporadically with slapindex -q<attribute> >> >> i.e., reindexing a single attribute instead of the entire DB > > Can't reproduce it here, need a test case. It's hard to come up with one. We've only had this one instance on one machine. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by hyc＠symas.com 09 Mar '11

09 Mar '11

Quanah Gibson-Mount wrote: > > > --On March 4, 2011 11:14:46 PM +0000 dhawes(a)vt.edu wrote: >> Tested, and working. Thanks for the fix. > > We're still seeing this happen sporadically with slapindex -q<attribute> > > i.e., reindexing a single attribute instead of the entire DB Can't reproduce it here, need a test case. -- -- 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#6461) back-sql quote characters in query
by hyc＠symas.com 09 Mar '11

09 Mar '11

atze_80(a)web.de wrote: > Can confirm this with openldap 2.4.24. Thanks, the bug was already confirmed. > > Using ldap search filters like this: > > (cn=blabla' or '1'='1) > > is at least causing my postgres to eat all CPU cycles it can get (LDAP > data is based on complex view). I do not have write access enabled for > that particular openLDAP installation, but I also assume that SQL > Injection is possible. Beside being an obviuos malfunction, this should > be considered a security issue. As the bug status says, "patches welcome." back-sql is not a priority for any of the core developers. -- -- 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#6858) segfault on schema modification in cn=config
by hyc＠symas.com 09 Mar '11

09 Mar '11

zerbe(a)phil.uni-duesseldorf.de wrote: > Full_Name: Sebastian Zerbe > Version: 2.4.23-7 > OS: Debian GNU/Linux 6.0 > URL: ftp://ftp.openldap.org/incoming/sebastian-zerbe-110309.tar.gz > Submission from: (NULL) (134.99.58.27) > > > Trying to modify the local schema cn={5}philfak,cn=schema,cn=config with the > given ldif-file modify_phil_schema.ldif using "ldapmodify -x -D > cn=admin,cn=config -W -f modify_phil_schema.ldif" results in a slapd crash with > kernel log entries like these: > > [3451954.217075] slapd[2593]: segfault at 70 ip 080bd73f sp ae5f9910 error 4 in > slapd[8048000+11b000] > [3451972.088717] slapd[5716]: segfault at 70 ip 080bd73f sp b1bfe910 error 4 in > slapd[8048000+11b000] > [3452718.916547] slapd[5830]: segfault at 70 ip 080bd73f sp b1992910 error 4 in > slapd[8048000+11b000] > > Further debugging is nearly impossible. If slapd is running in gdb it does not > crash (but the modifications do not take place either)... The crash has been fixed in HEAD, but your mod request will still fail because Delete is not supported for olcObjectIdentifier attributes. -- -- 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#6858) segfault on schema modification in cn=config
by zerbe＠phil.uni-duesseldorf.de 09 Mar '11

09 Mar '11

Full_Name: Sebastian Zerbe Version: 2.4.23-7 OS: Debian GNU/Linux 6.0 URL: ftp://ftp.openldap.org/incoming/sebastian-zerbe-110309.tar.gz Submission from: (NULL) (134.99.58.27) Trying to modify the local schema cn={5}philfak,cn=schema,cn=config with the given ldif-file modify_phil_schema.ldif using "ldapmodify -x -D cn=admin,cn=config -W -f modify_phil_schema.ldif" results in a slapd crash with kernel log entries like these: [3451954.217075] slapd[2593]: segfault at 70 ip 080bd73f sp ae5f9910 error 4 in slapd[8048000+11b000] [3451972.088717] slapd[5716]: segfault at 70 ip 080bd73f sp b1bfe910 error 4 in slapd[8048000+11b000] [3452718.916547] slapd[5830]: segfault at 70 ip 080bd73f sp b1992910 error 4 in slapd[8048000+11b000] Further debugging is nearly impossible. If slapd is running in gdb it does not crash (but the modifications do not take place either)...

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 08 Mar '11

08 Mar '11

--On March 4, 2011 11:14:46 PM +0000 dhawes(a)vt.edu wrote: > Tested, and working. Thanks for the fix. We're still seeing this happen sporadically with slapindex -q <attribute> i.e., reindexing a single attribute instead of the entire DB Thread 2 (Thread 0x96591ba0 (LWP 10652)): #0 0xffffe410 in __kernel_vsyscall () No symbol table info available. #1 0xb7dd21e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0xb7f4b5d8 in ldap_pvt_thread_cond_wait (cond=0xb776bf80, mutex=0xb776bf50) at thr_posix.c:277 No locals. #3 0xb77376f4 in bdb_tool_trickle_task (ctx=0x965912bc, ptr=0x82eb728) at tools.c:1242 env = 0x82eb728 wrote = -1208699249 #4 0xb7f4a33c in ldap_int_thread_pool_wrapper (xpool=0x81bda78) at tpool.c:685 pool = 0x81bda78 task = 0x82ee038 work_list = 0x81bdaf8 ctx = {ltu_id = 2522422176, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0xb7f9b049, ltk_free = 0xb7dcc732}, { ltk_key = 0x0, ltk_data = 0xb7fa7ff4, ltk_free = 0xb7bffd80}, {ltk_key = 0x0, ltk_data = 0x96591388, ltk_free = 0xb7f963d0 <do_lookup_x+640>}, {ltk_key = 0x0, ltk_data = 0xb7dcc75a, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0xb7dcb324, ltk_free = 0x69cb120}, {ltk_key = 0x0, ltk_data = 0xd696910, ltk_free = 0xe}, {ltk_key = 0x0, ltk_data = 0xb7a874a0, ltk_free = 0xb7a8ffe0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x2, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0xb7fa7ff4}, {ltk_key = 0x0, ltk_data = 0x96591414, ltk_free = 0x96591428}, { ltk_key = 0x0, ltk_data = 0x96591414, ltk_free = 0xb7fa8830}, {ltk_key = 0x0, ltk_data = 0xb7bf7dd8, ltk_free = 0x1}, {ltk_key = 0x0, ltk_data = 0x1, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0xb7f272a0, ltk_free = 0xb7dcb69d}, {ltk_key = 0x0, ltk_data = 0x1000000, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0xb7a8f000, ltk_free = 0xb7bf7508}, {ltk_key = 0x0, ltk_data = 0xb7dcb324, ltk_free = 0xb7f272a0}, {ltk_key = 0x0, ltk_data = 0xb7f9a24d, ltk_free = 0xb7f27448}, {ltk_key = 0x0, ltk_data = 0x1, ltk_free = 0x1}}} kctx = 0x0 i = 32 keyslot = 522 hash = 5777930 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #5 0xb7dce35b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #6 0xb7b43c0e in clone () from /lib/libc.so.6 No symbol table info available. Thread 1 (Thread 0xb7a826b0 (LWP 10610)): #0 0xffffe410 in __kernel_vsyscall () No symbol table info available. #1 0xb7dd21e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0xb7f4b5d8 in ldap_pvt_thread_cond_wait (cond=0x81bda94, mutex=0x81bda7c) at thr_posix.c:277 No locals. #3 0xb7f49fe7 in ldap_pvt_thread_pool_destroy (tpool=0xbf995780, run_pending=0) at tpool.c:582 pool = 0x81bda78 pptr = 0x81bda78 task = 0x0 #4 0xb7f49332 in ldap_int_thread_pool_shutdown () at tpool.c:181 pool = 0x81bda78 #5 0xb7f48aa0 in ldap_pvt_thread_destroy () at threads.c:70 No locals. #6 0x080af918 in slap_destroy () at init.c:273 rc = 0 #7 0x080ff5f2 in slap_tool_destroy () at slapcommon.c:865 rc = 0 #8 0x080ffb9b in slapindex (argc=1, argv=0xbf9959bc) at slapindex.c:107 id = 4294967295 rc = 0 progname = 0x813ae0a "slapindex" ad = 0x8239440 adv = 0xbf9959bc __PRETTY_FUNCTION__ = "slapindex" #9 0x08057783 in main (argc=7, argv=0xbf9959a4) at main.c:403 i = 3 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 7 g_argv = 0xbf9959a4 configfile = 0x0 configdir = 0x0 serverName = 0xbf997206 "slapindex" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x811c33f "" l = 134548137 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main" --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6461) back-sql quote characters in query
by atze_80＠web.de 08 Mar '11

08 Mar '11

Can confirm this with openldap 2.4.24. Using ldap search filters like this: (cn=blabla' or '1'='1) is at least causing my postgres to eat all CPU cycles it can get (LDAP data is based on complex view). I do not have write access enabled for that particular openLDAP installation, but I also assume that SQL Injection is possible. Beside being an obviuos malfunction, this should be considered a security issue. atze

1 0

Re: (ITS#6856) OpenLDAP 2.4.23 / db 4.7.25 lockup 100% CPU
by hyc＠symas.com 07 Mar '11

07 Mar '11

requate(a)univention.de wrote: > Full_Name: Arvid Requate > Version: 2.4.23 > OS: Debian Lenny > URL: http://apt.univention.de/download/temp/openldap/trace_openldap_2.4.23_db_4.… > Submission from: (NULL) (82.198.197.8) > > > With OpenLDAP 2.4.23 and bdb 4.7.25 we seem to hit something like a race > condition that can be triggered by concurrent ldapdelete and search_s > operations. > Though a bit simmilar, this condition does no quite match the details of > ITS#5707. The URL provides a tar archive containing three gdb traces and > corresponding slapd log output (loglevel: trace args stats) of three cases of > lockup, where slapd hangs consuming 100% of CPU after a couple of modifications > with the shell script contained in the tar archive and remains unresponsive > until restartet.The number of successful operations varies between the test > runs. > > Berkeley DB 4.7.25 (May 15, 2008) was built with Oracle patches for Bugs #16415 > and #16541 and configure options "--enable-posixmutexes > --with-mutex=POSIX/pthreads". > > The test machine is a single processor/single core 686 VM running Linux 2.6.32 > 686 bigmem. The concurrent searches are performed by a separate process that > gets informed about ldap modifications (via file) by an slapd overlay module > called 'translog'. To me the traces do not seem to indicate a problem in the > overlay code (i.e. there is no reference to the on_response function > "translog_response" in the traces). > > Maybe there is some obvious point here we are missing? More debug details can be > provided if necessary. Try again using 2.4.24. There was a bug with back-bdb delete fixed recently (ITS#6577) so the relevant code has changed since .23. Also try a newer BerkeleyDB. We've had other deadlocks with 4.7 that no longer occur in 4.8. -- -- 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#6857) chain overlay change FLAGS of underlying database
by rhafer＠suse.de 07 Mar '11

07 Mar '11

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.38.247) The chain-overlay adds SLAP_DBFLAG_NOLASTMOD to the flags of the database for which chaining is to be configured. Example: -------------------- database hdb suffix o=test rootdn o=test rootpw secret directory /tmp/ldap overlay chain chain-return-error TRUE chain-uri ldap://ldap.server ------------------- With the above configuration slapd will no longer maintain the "modifyTimeStamp", "modifiersName", etc. Attributes for write operations to the "o=test" database anymore. Note: This bug is only present when using a slapd.conf base configuration. Fix is almost ready.

1 0

(ITS#6856) OpenLDAP 2.4.23 / db 4.7.25 lockup 100% CPU
by requate＠univention.de 07 Mar '11

07 Mar '11

Full_Name: Arvid Requate Version: 2.4.23 OS: Debian Lenny URL: http://apt.univention.de/download/temp/openldap/trace_openldap_2.4.23_db_4.… Submission from: (NULL) (82.198.197.8) With OpenLDAP 2.4.23 and bdb 4.7.25 we seem to hit something like a race condition that can be triggered by concurrent ldapdelete and search_s operations. Though a bit simmilar, this condition does no quite match the details of ITS#5707. The URL provides a tar archive containing three gdb traces and corresponding slapd log output (loglevel: trace args stats) of three cases of lockup, where slapd hangs consuming 100% of CPU after a couple of modifications with the shell script contained in the tar archive and remains unresponsive until restartet.The number of successful operations varies between the test runs. Berkeley DB 4.7.25 (May 15, 2008) was built with Oracle patches for Bugs #16415 and #16541 and configure options "--enable-posixmutexes --with-mutex=POSIX/pthreads". The test machine is a single processor/single core 686 VM running Linux 2.6.32 686 bigmem. The concurrent searches are performed by a separate process that gets informed about ldap modifications (via file) by an slapd overlay module called 'translog'. To me the traces do not seem to indicate a problem in the overlay code (i.e. there is no reference to the on_response function "translog_response" in the traces). Maybe there is some obvious point here we are missing? More debug details can be provided if necessary.

1 0

Re: (ITS#6491) LDAP Error code 80 - Dn index delete failed
by apm＠one.com 07 Mar '11

07 Mar '11

I see this symptom too with both these versions: OpenLDAP 2.4.21, BDB 4.8.26 OpenLDAP 2.4.23, BDB 4.8.30 ldapdelete -r failes with: ldap_delete: Other (e.g., implementation specific) error (80) additional info: DN index delete failed I've copied the database files to a similar machine for debugging. Here's the output for slapd -d1 when doing so: ============================================================= do_bind: SASL/EXTERNAL bind: dn="cn=config" sasl_ssf=0 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 11 <== slap_sasl_bind: rc=0 connection_get(11): got connid=1001 connection_read(11): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 86 contents: op tag 0x63, time 1299502775 ber_get_next conn=1001 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <o=xxx,dc=example,dc=com> <<< dnPrettyNormal: <o=xxx,dc=example,dc=com>, <o=xxx,dc=example,dc=com> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: => bdb_search bdb_dn2entry("o=xxx,dc=example,dc=com") search_candidates: base="o=xxx,dc=example,dc=com" (0x0025d3ca) scope=1 => bdb_dn2idl("o=xxx,dc=example,dc=com") <= bdb_dn2idl: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) bdb_search_candidates: failed (rc=-30988) bdb_search: no candidates send_ldap_result: conn=1001 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 14 bytes to sd 11 connection_get(11): got connid=1001 connection_read(11): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 49 contents: op tag 0x4a, time 1299502775 ber_get_next conn=1001 op=2 do_delete ber_scanf fmt (m) ber: >>> dnPrettyNormal: <o=xxx,dc=example,dc=com> <<< dnPrettyNormal: <o=xxx,dc=example,dc=com>, <o=xxx,dc=example,dc=com> bdb_dn2entry("o=xxx,dc=example,dc=com") bdb_dn2entry("o=xxx,dc=example,dc=com") bdb_entry_get: rc=0 bdb_dn2entry("o=xxx,dc=example,dc=com") => bdb_dn2id_delete 0x25d3ca: "o=xxx,dc=example,dc=com" => bdb_idl_delete_key: c_get lo failed: DB_BUFFER_SMALL: User memory too small for return value (-30999) => bdb_dn2id_delete 0x25d3ca: subtree (o=xxx,dc=example,dc=com) delete failed: -30999 <= bdb_dn2id_delete 0x25d3ca: -30999 <=- bdb_delete: dn2id failed: DB_BUFFER_SMALL: User memory too small for return value (-30999) send_ldap_result: conn=1001 op=2 p=3 send_ldap_response: msgid=3 tag=107 err=80 ber_flush2: 36 bytes to sd 11 connection_get(11): got connid=1001 connection_read(11): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 5 contents: op tag 0x42, time 1299502775 ber_get_next ber_get_next on fd 11 failed errno=0 (Success) conn=1001 op=3 do_unbind connection_get(11): got connid=1001 connection_get(11): got connid=1001 connection_close: conn=1001 sd=11 ============================================================================= Doing an ldapsearch for the entry takes some time, but does finish. Looking at the -d1 output there's a lot of "bdb_search: <number> scope not okay" messages. There's about 5 million objects in the database. I only know of this one object on this server which has this problem. I have another server with another object with the same problem. Other objects can be deleted just fine. Looking at the slapcat output, there's only the base "o=xxx" object. There's no subordinate objects to this object. /Peter

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 07 Mar '11

07 Mar '11

Hi, Le Ven 4 mars 2011 23:02, hyc(a)symas.com a écrit : > raphael.ouazana(a)linagora.com wrote: >> Le Mer 2 mars 2011 17:52, masarati(a)aero.polimi.it a ?crit : >>> >>>> The following patch >>> >>> Please upload patches according to >>> <http://www.openldap.org/devel/contributing.html#submitting>. >> >> Sorry, it seems to be my fault. Here it is: >> ftp://ftp.openldap.org/incoming/raphael-ouazana-110302-sssvlv-fix-free_sort… > > Thanks for the patch. While you're at it, would you be able to create a > test > script for sssvlv to use in our test suite? Sorry, no time for that for the moment. Furthermore I don't think this bug is reproducible with current OpenLDAP client tools. Regards, Raphaël Ouazana.

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by dhawes＠vt.edu 04 Mar '11

04 Mar '11

On 03/04/2011 05:56 PM, hyc(a)symas.com wrote: > dhawes(a)vt.edu wrote: >> On 03/04/2011 04:08 PM, hyc(a)symas.com wrote: >>> This indicates that the trickle task is still waiting for a signal on its >>> condition variable. Which is a bit odd since bdb_tool_entry_close() already >>> signals it before slap_tool_destroy() is called. >>> >>> It might be illuminating to run slapadd under gdb with a breakpoint on >>> bdb_tool_entry_close(), and singlestep through the first few lines of that >>> function where it issues the signal, and see if the trickle task actually >>> reacts or not. >> >> Setting a breakpoint on bdb_tool_entry_close() and then either >> continuing or stepping through the function allows slapadd to exit cleanly. > > A fix for this is now in HEAD, please test. > back-bdb/tools.c 1.140 > Tested, and working. Thanks for the fix.

1 0

Re: (ITS#6817) idassert-bind with SASL issues
by hyc＠symas.com 04 Mar '11

04 Mar '11

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: HEAD/re24 >>> OS: irrelevant >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (2.40.14.92) >>> Submitted by: ando >>> >>> >>> When idassert-bind is configured to use SASL bind, an "authcID" needs to >>> be >>> provided, while the "binddn" is not needed. However, if a "binddn" is >>> not >>> provided as well, in some cases the proxiedAuthz control may be used >>> incorrectly. The need to configure the "binddn" is not documented, so >>> this ITS >>> is minimally addressed by documenting this requirement. >> >> I tripped over this change while investigating #6711. Adding this >> requirement >> is certainly not the right solution; SASL Binds ordinarily don't require a >> BindDN and requiring it here just makes things confusing. > > I understand the fix I'm suggesting can sound counter-intuitive. The > documentation should clearly indicate that the binddn in case of SASL is > for *local* and *internal* issues, and will not be part of the > authentication process. As an alternative, lc_bound_ndn could receive a > dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive > the actual identity from the remote server using the authid control along > with the bind or performing a whoami extop later, as already implemented). Using a dummy DN here sounds OK. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6855) Suggested improvements to OpenLDAP Admin Guide preface
by hyc＠symas.com 04 Mar '11

04 Mar '11

gerv(a)mozilla.org wrote: > Full_Name: Gervase Markham > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.45.122.200) > > > Following a discussion on the mailing list, I submit the following as a > suggestion for improvement to the Preface of the Admin Guide, to make it clear > that there are other documentation resources which should be read. Thanks. I've committed some of this suggestion to CVS HEAD. I would expect an experienced sysadmin to already know which manpage sections are relevant, and I don't believe a sysadmin needs to read the API documentation. > <snip> > This document is not a complete guide to its subject matter; the man pages are > the definitive documentation for OpenLDAP software. For best results, you should > use those installed on your system, which will match your version of OpenLDAP. > But they are also available on the web from the following links: > > OpenLDAP API: > > <ul> > <li><a href="http://www.openldap.org/software/man.cgi?query=ldap">ldap(3)</a> > </ul> > > OpenLDAP configuration: > > <ul> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.conf">slapd.conf(5)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapd-config">slapd-config(5)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.access">slapd.access(5)</a> > </ul> > > OpenLDAP command line tools: > > <ul> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapacl">slapacl(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapadd">slapadd(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapauth">slapauth(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapcat">slapcat(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapdn">slapdn(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapindex">slapindex(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slappasswd">slappasswd(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapschema">slapschema(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slaptest">slaptest(8) > </ul> > > Gerv > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs