openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(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

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