openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

Re: (ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by crispy＠cluenet.org 31 Mar '10

31 Mar '10

Hi, any word on if this can be incorporated? Thanks. On Sun, 2010-03-07 at 01:24 +0000, openldap-its(a)OpenLDAP.org wrote: > *** 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#6488. > > 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#6488) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6488) > > 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=6488 > > Please remember to retain your issue tracking number (ITS#6488) > 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. >

1 0

Re: (ITS#6501) DBTzeros in bdb/hdb
by hyc＠symas.com 30 Mar '10

30 Mar '10

mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: 2.4, HEAD > OS: any > URL: > Submission from: (NULL) (76.88.107.46) > > > The lockobj's in BDB aren't being DBTzero()'d fully before use; they > consist of more than just .data and .size, so this leaves uninit > memory that gets branched on. > > Needs to be applied to HEAD and 2.4. (2.3 as well, for those still > tracking that for some reason, probably all branches with BDB/HDB) Thanks, fixed in HEAD. The dn2id.c patch is obsolete, that function is no longer used. > > Patch vs HEAD: > > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/cache.c,v > retrieving revision 1.214 > diff -u -u -r1.214 cache.c > --- cache.c 4 Nov 2009 05:09:51 -0000 1.214 > +++ cache.c 29 Mar 2010 16:41:59 -0000 > @@ -184,6 +184,7 @@ > > if ( !lock ) return 0; > > + DBTzero(&lockobj ); > lockobj.data =&ei->bei_id; > lockobj.size = sizeof(ei->bei_id) + 1; > > @@ -225,6 +226,7 @@ > else > db_rw = DB_LOCK_READ; > > + DBTzero(&lockobj ); > lockobj.data =&ei->bei_id; > lockobj.size = sizeof(ei->bei_id) + 1; > > Index: dn2id.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/dn2id.c,v > retrieving revision 1.169 > diff -u -u -r1.169 dn2id.c > --- dn2id.c 15 Feb 2010 14:25:47 -0000 1.169 > +++ dn2id.c 29 Mar 2010 16:41:59 -0000 > @@ -42,6 +42,7 @@ > else > db_rw = DB_LOCK_READ; > > + DBTzero(&lockobj ); > lockobj.data = dn->bv_val; > lockobj.size = dn->bv_len; > > -- -- 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#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by masarati＠aero.polimi.it 30 Mar '10

30 Mar '10

> On Tue, 2010-03-02 at 15:30 +1100, Andrew Bartlett wrote: >> On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote: >> > [Resending because I forgot the ITS number in the subject] >> > >> > I have a simple prototype that on add/modrdn populates/maintains an >> > attribute (rdnValue) with the distinguished values of the naming >> > attributes of the RDN. While doing this, it also checks for >> uniqueness of >> > the rdnValue value within siblings. >> > >> > You can find it here >> > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.c> >> > >> > Please test and comment. I hope it does what intended. >> >> I'm starting to look at this now. I'm sorry so many months have past >> since you posted it. > > I've now added it into Samba's provision, and using the diff I attach, > against current 'master', I get the attached error. > > It seems to be unable to add the base DN. (The very first entry in the > database). Try this: <www.aero.polimi.it/masarati/Download/pierangelo-masarati-2010-03-30-rdnval.…>. In fact, when adding the suffix entry, the overlay was erroneously checking its siblings from its superior, which is very likely to fail. p.

1 0

Re: (ITS#6500) get_ldap_property returns stale data from time to time
by alinachegalati＠yahoo.com 30 Mar '10

30 Mar '10

--0-808694875-1269950414=:35747 Content-Type: text/plain; charset=us-ascii i was using the deprecated function from openldap. i switched to ldap_value_free_len, i'll run more tests to see if i still have the problem. ________________________________ From: "masarati(a)aero.polimi.it" <masarati(a)aero.polimi.it> To: alinachegalati(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Tue, March 30, 2010 7:15:51 AM Subject: Re: (ITS#6500) get_ldap_property returns stale data from time to time Not clear why you think this is an OpenLDAP bug. There's too little information to determine whether your application is using OpenLDAP's client library correctly. p. > Full_Name: Alin Vasile > Version: 2.4.19 > OS: SuSE 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.17) > > > Hi, > > In a high load apache environment I am performing some ldap searches for > some > requests using a custom developed application and the OpenLdap client > libraries. >>From time to time I have the following segmentation fault: > > Program terminated with signal 11, Segmentation fault. > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > 30 if ( v != NULL && v[0] != NULL ) { > (gdb) backtrace > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, > ldap_request=0x76ff60) at ldap_query.c:353 > > And the function is : > > char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, > apr_pool_t* context) { > > char ** v = ldap_get_values(ldap, entry, attribute); > > if ( v != NULL && v[0] != NULL ) { > char* ret = apr_pstrdup(context, v[0] ); > ldap_value_free( v ); > return ret; > } > > return NULL; > > } > > Note that most of the queries (99%) work fine. > > Did anyone experienced something simmilar? > > Thanks, > Alin > --0-808694875-1269950414=:35747 Content-Type: text/html; charset=us-ascii <html><head><style type="text/css"></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div> </div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">i was using the deprecated function from openldap. i switched to ldap_value_free_len, i'll run more tests to see if  i still have the problem. <div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><hr size="1">From: "masarati(a)aero.polimi.it" <masarati(a)aero.polimi.it> To: alinachegalati(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Tue, March 30, 2010 7:15:51 AM Subject: Re: (ITS#6500) get_ldap_property returns stale data from time to time Not clear why you think this is an OpenLDAP bug.  There's too little information to determine whether your application is using OpenLDAP's client library correctly. p. > Full_Name: Alin Vasile > Version: 2.4.19 > OS: SuSE 11 > URL: <a href="ftp://ftp.openldap.org/incoming/" target="_blank">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (194.237.142.17) > > > Hi, > >  In a high load apache environment I am performing some ldap searches for > some > requests using a custom developed application and the OpenLdap client > libraries. >>From time to time I have the following segmentation fault: > > Program terminated with signal 11, Segmentation fault. > #0  0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) >    at ldap_query.c:30 > 30          if ( v != NULL && v[0] != NULL ) { > (gdb) backtrace > #0  0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) >    at ldap_query.c:30 > #1  0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, > ldap_request=0x76ff60) at ldap_query.c:353 > > And the function is : > > char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, > apr_pool_t* context) { > >    char ** v = ldap_get_values(ldap, entry, attribute); > >    if ( v != NULL && v[0] != NULL ) { >        char* ret = apr_pstrdup(context,  v[0] ); >        ldap_value_free( v ); >        return ret; >    } > >    return NULL; > > } > > Note that most of the queries (99%) work fine. > > Did anyone experienced something simmilar? > > Thanks, > Alin > </div></div> </div> </body></html> --0-808694875-1269950414=:35747--

1 0

Re: (ITS#6502) Build failure tls_g.c
by hyc＠symas.com 30 Mar '10

30 Mar '10

This is a dup of ITS#5930 (and probably a few others). Solaris ships with a prehistoric version of GnuTLS (even before they added version stamps to the gnutls.h header file). You cannot use it. Use OpenSSL or install a recent version of GnuTLS instead. kenneth.greiner(a)paetec.com wrote: > Full_Name: Ken Greiner > Version: 2.4.21 > OS: SunOS 5.10 Generic_141445-09 i86pc i386 i86pc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.80.108.55) > > > ./configure --disable-slapd --prefix=$HOME > OK > ./make depend > OK > ./make > ... lots of good stuff.. then -> > > /bin/sh ../../libtool --mode=compile gcc -g -O2 -I../../include > -I../../include -DLDAP_LIBRARY -c tls_g.c > gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c -fPIC > -DPIC -o .libs/tls_g.o > tls_g.c:73: error: syntax error before "gnutls_kx_algorithm_t" > tls_g.c:73: warning: no semicolon at end of struct or union > tls_g.c:74: warning: data definition has no type or storage class > tls_g.c:75: error: syntax error before "mac" > tls_g.c:75: warning: data definition has no type or storage class > .. and so on. > oops! Failed on this tls_g.c file. > > -- -- 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#6500) get_ldap_property returns stale data from time to time
by masarati＠aero.polimi.it 29 Mar '10

29 Mar '10

Not clear why you think this is an OpenLDAP bug. There's too little information to determine whether your application is using OpenLDAP's client library correctly. p. > Full_Name: Alin Vasile > Version: 2.4.19 > OS: SuSE 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.17) > > > Hi, > > In a high load apache environment I am performing some ldap searches for > some > requests using a custom developed application and the OpenLdap client > libraries. >>From time to time I have the following segmentation fault: > > Program terminated with signal 11, Segmentation fault. > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > 30 if ( v != NULL && v[0] != NULL ) { > (gdb) backtrace > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, > ldap_request=0x76ff60) at ldap_query.c:353 > > And the function is : > > char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, > apr_pool_t* context) { > > char ** v = ldap_get_values(ldap, entry, attribute); > > if ( v != NULL && v[0] != NULL ) { > char* ret = apr_pstrdup(context, v[0] ); > ldap_value_free( v ); > return ret; > } > > return NULL; > > } > > Note that most of the queries (99%) work fine. > > Did anyone experienced something simmilar? > > Thanks, > Alin >

1 0

(ITS#6502) Build failure tls_g.c
by kenneth.greiner＠paetec.com 29 Mar '10

29 Mar '10

Full_Name: Ken Greiner Version: 2.4.21 OS: SunOS 5.10 Generic_141445-09 i86pc i386 i86pc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.80.108.55) ./configure --disable-slapd --prefix=$HOME OK ./make depend OK ./make ... lots of good stuff.. then -> /bin/sh ../../libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c -fPIC -DPIC -o .libs/tls_g.o tls_g.c:73: error: syntax error before "gnutls_kx_algorithm_t" tls_g.c:73: warning: no semicolon at end of struct or union tls_g.c:74: warning: data definition has no type or storage class tls_g.c:75: error: syntax error before "mac" tls_g.c:75: warning: data definition has no type or storage class .. and so on. oops! Failed on this tls_g.c file.

1 0

(ITS#6501) DBTzeros in bdb/hdb
by mbackes＠symas.com 29 Mar '10

29 Mar '10

Full_Name: Matthew Backes Version: 2.4, HEAD OS: any URL: Submission from: (NULL) (76.88.107.46) The lockobj's in BDB aren't being DBTzero()'d fully before use; they consist of more than just .data and .size, so this leaves uninit memory that gets branched on. Needs to be applied to HEAD and 2.4. (2.3 as well, for those still tracking that for some reason, probably all branches with BDB/HDB) Patch vs HEAD: =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/cache.c,v retrieving revision 1.214 diff -u -u -r1.214 cache.c --- cache.c 4 Nov 2009 05:09:51 -0000 1.214 +++ cache.c 29 Mar 2010 16:41:59 -0000 @@ -184,6 +184,7 @@ if ( !lock ) return 0; + DBTzero( &lockobj ); lockobj.data = &ei->bei_id; lockobj.size = sizeof(ei->bei_id) + 1; @@ -225,6 +226,7 @@ else db_rw = DB_LOCK_READ; + DBTzero( &lockobj ); lockobj.data = &ei->bei_id; lockobj.size = sizeof(ei->bei_id) + 1; Index: dn2id.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/dn2id.c,v retrieving revision 1.169 diff -u -u -r1.169 dn2id.c --- dn2id.c 15 Feb 2010 14:25:47 -0000 1.169 +++ dn2id.c 29 Mar 2010 16:41:59 -0000 @@ -42,6 +42,7 @@ else db_rw = DB_LOCK_READ; + DBTzero( &lockobj ); lockobj.data = dn->bv_val; lockobj.size = dn->bv_len;

1 0

(ITS#6500) get_ldap_property returns stale data from time to time
by alinachegalati＠yahoo.com 29 Mar '10

29 Mar '10

Full_Name: Alin Vasile Version: 2.4.19 OS: SuSE 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.17) Hi, In a high load apache environment I am performing some ldap searches for some requests using a custom developed application and the OpenLdap client libraries. >From time to time I have the following segmentation fault: Program terminated with signal 11, Segmentation fault. #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, entry=0x841160, attribute=0x87aa50 "smIMEI", context=0x76fc38) at ldap_query.c:30 30 if ( v != NULL && v[0] != NULL ) { (gdb) backtrace #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, entry=0x841160, attribute=0x87aa50 "smIMEI", context=0x76fc38) at ldap_query.c:30 #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, ldap_request=0x76ff60) at ldap_query.c:353 And the function is : char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, apr_pool_t* context) { char ** v = ldap_get_values(ldap, entry, attribute); if ( v != NULL && v[0] != NULL ) { char* ret = apr_pstrdup(context, v[0] ); ldap_value_free( v ); return ret; } return NULL; } Note that most of the queries (99%) work fine. Did anyone experienced something simmilar? Thanks, Alin

1 0

Re: (ITS#6490) dds and pcache overlays not checking NULL value
by etienne.bagnoud＠irovision.ch 29 Mar '10

29 Mar '10

--Sig_/_7pgY/8RXQkx3sc0s2ymL2R Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I've tested dds and it seems fine to me. Thanks. --Sig_/_7pgY/8RXQkx3sc0s2ymL2R Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJLsH3qAAoJEMFfL/bTFBa43e8P/A2TTN5sAFs8x6G7W2mKq/UA R3UcfP0gH1IfxW8eM6ZkIxgi+hI9f0fPEZf1j9KgC4baKsof50jeKBKrx3+iholH oItObH9D2feLIJL3cd+mYyS0mYZOhmD5KtS2cwLwlpgK3HS5crZJYrV0rPctD/xR kCmFcSpX3+KsQaksEqPHMN6Tac3N600yiBs6L9WF5L4Vor1eAVUh10qomr0SVeQ2 zpw8IZBMhUjnn88tJJSWy96Ig0gUeUpKym0jJg8Nsh7AlSd4FpSUKOMjmfSwpfNT VFFTOb7KulyMdvFipZbJ02t5Pgw05zJKfucsGje57YTWUdW2AtpF/sFrh48ULo0x u/cdI2P8NH5ht7VnLVZkYp70vT93G6Jg14RmMGv1Nl6Qsv2S4dNxMo73En8Prwwk RbuEtFcvUNPDXUaB6IATSi4JcLTTFaTZJkKqTlJHB/pVaFUDLLtdIYdWJnOJMb8L PemlIgVU9l9W83WQMmaGoHOdK7EW9TLHeew0uhsP8hoJIydqYIhWO9iyhkdhVV9Q Z9TrN3D1MElanEU4ljMt9QyBHO6IuwW61PsLAjgN+a3H46DWVDhReJa7/27nwGfg PI8YzlDWmaBjsBCFxwu2ppTCsEQy7SOBesTy+Tx5++aZFO/lmPZT8scbfBK4I+O0 gCQitsPuhA5DwP6UMDKG =r9DC -----END PGP SIGNATURE----- --Sig_/_7pgY/8RXQkx3sc0s2ymL2R--

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