openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#5281) doc contribution - set examples - following references
by andreas＠mandriva.com.br 02 Jan '08

02 Jan '08

On Wed, Jan 02, 2008 at 02:53:06PM +0000, Gavin Henry wrote: > It's up for discussion if the ACL discussion in the current config sections > of the admin guide should stay there or be moved out into their own. I think the ACLs should be moved to their own section, like the man pages already have done. We have a man page for slapd.conf and another specific one for the ACLs (slapd.access)

1 0

Re: (ITS#5304) bug in source code: libldap/extended.c ?
by ando＠sys-net.it 02 Jan '08

02 Jan '08

I've patched it differently in HEAD (rev. 1.44); please check. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5304) bug in source code: libldap/extended.c ?
by mark.funkenhauser＠bluecoat.com 02 Jan '08

02 Jan '08

Correction to suggested fix: I think the code at line 374 should look like: if ( ber_scanf( ber, /*{*/ "}" ) == LBER_ERROR ) { ld->ld_errno = LDAP_DECODING_ERROR; ber_free( ber, 0 ); if( resoid != NULL ) LDAP_FREE( resoid ); if (resdata != NULL) ber_bvfree( resdata ); return ld->ld_errno; }

1 0

(ITS#5304) bug in source code: libldap/extended.c ?
by mark.funkenhauser＠bluecoat.com 02 Jan '08

02 Jan '08

Full_Name: Mark Funkenhauser Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.16.247.2) Looking at libldap/extended.c, rev 1.43, function ldap_parse_intermediate(), at line 374, the code is written as: if ( ber_scanf( ber, /*{*/ "}" ) == LBER_ERROR ) { rc = LDAP_DECODING_ERROR; goto free_and_return; } I think there's a problem here. 1) rc is defined to be a ber_tag_t type, which is not suitable for assignment to an LDAP_*_ERROR error code. ber_tag_t is an unsigned type, and LDAP_DECODING_ERROR is a negative number. 2) The use of LDAP_DECODING_ERROR here implies there is an error. I would have thought this function should be returning this error code using "return ld->ld_errno". Jumping to "free_and_return" is not the way to return an error. 3) the "goto free_and_return" is a jump to code to handle a successful return from this function. Assigning any value to rc before this "goto" becomes a no-op because the code after "free_and_return" does not use rc. I think the code at line 374 should look like: if ( ber_scanf( ber, /*{*/ "}" ) == LBER_ERROR ) { ld->ld_errno = LDAP_DECODING_ERROR; ber_free( ber, 0 ); if( resoid != NULL ) LDAP_FREE( resoid ); return ld->ld_errno; }

1 0

Re: (ITS#5281) doc contribution - set examples - following references
by ghenry＠OpenLDAP.org 02 Jan '08

02 Jan '08

andreas(a)mandriva.com.br wrote: > Full_Name: Andreas Hasenack > Version: 2.4.6 > OS: Linux > URL: http://users.mandriva.com.br/~andreas/ldap-doc/doc-set-examples/set-followi… > Submission from: (NULL) (200.140.247.99) > > > http://users.mandriva.com.br/~andreas/ldap-doc/doc-set-examples/set-followi… > > Documentation contribution with further examples regarding the usage of sets in > ACLs. This time, using a user/manager/secretary/group example. > > These files are derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Andreas Hasenack <andreas(a)mandriva.com.br>. These modifications are not subject > to any license of Mandriva. > I, Andreas Hasenack, 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. > > Thanks for this Andreas. I'll be working on a sets section in the ACL section shortly. It's up for discussion if the ACL discussion in the current config sections of the admin guide should stay there or be moved out into their own. More later. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5303) idlcache problem with new entries
by hyc＠symas.com 31 Dec '07

31 Dec '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.39 > OS: NA > URL: ftp://ftp.openldap.org/incoming/idlcache-bug.tar.gz > Submission from: (NULL) (76.21.80.71) > > > While testing heavy account provisioning using multiple threads to create > accounts in an OpenLDAP server, we discovered that the idl cache fails to > properly update, making searches for successfully added accounts fail to find > them. Setting the idlcachesize to zero resolved the search problem, indicating > an issue inside the idl cache code. This is a dup of ITS#5086, fixed in HEAD. Please test... > Zimbra bug is here: > > http://bugzilla.zimbra.com/show_bug.cgi?id=22933 > > > Description: > ============ > - OpenLDAP build: openldap-2.3.39 > - 20 concurrent threads are ADDing (distinct) entries in a loop under a > common base DN. > - It seems intermittently upon DB_LOCK_DEADLOCK errors, the integrity of > indexes are broken > for a period of time even after the ADD returns a good code(err=0). > Search filtered on an indexed > attribute of the newly ADDed entry cannot be found. If the same query is > done again later, it > did find the entry. > - This seems to happen only after "many" DB_LOCK_DEADLOCK errors. The > search failure usually happens > after 20 to 80 iterations into the loop, while the deadlock error would > start happening since earlier > iterations. > > Notes on info in attached slapd.log: > ==================================== > 1. The described test started on line 996. > > 2. Line 25510 shows the ADD > Dec 20 14:45:51 phoebe slapd[209]: conn=2235 op=1 ADD > dn="uid=a-120-thread-3,ou=people,dc=test-accounts-20071220-143806,dc=ldaptest" > > 3. Line 25542 shows the ADD was successful > Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=1 RESULT tag=105 err=0 > text= > > This entry should contain (among other attributes): > objectClass: zimbraAccount > zimbraId: be0b628b-b8d1-4fce-99cd-7b7f6864149a > > 4. Line 25549 - 25550 shows the search on that zimbraId returned 0 entry: > Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=2 SRCH base="" scope=2 > deref=3 filter="(&(zimbraId=be0b628b-b8d1-4fce-99cd-7b7f6864149a)(objectClass=zimbraAccount))" > Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=2 SEARCH RESULT tag=101 > err=0 nentries=0 text= > > 5. Later, the same search(as in 3) was attempted. Line 25756 - 25757 shows the > same query did find one entry this time: > Dec 20 14:48:25 phoebe slapd[209]: conn=2250 op=1 SRCH base="" scope=2 > deref=3 filter="(&(zimbraId=be0b628b-b8d1-4fce-99cd-7b7f6864149a)(objectClass=zimbraAccount))" > Dec 20 14:48:25 phoebe slapd[209]: conn=2250 op=1 SEARCH RESULT tag=101 > err=0 nentries=1 text= > > 6. As shown in the log, there was no MOD or anything on DN > dn="uid=a-120-thread-3,ou=people,dc=test-accounts-20071220-143806,dc=ldaptest" > between 3 and 4. > > 7. Other info: > - zimbraId is an indexed attribute. see slapd.conf. > - Note, the test stops when it encounters the first failed search after a > successful create. > > > > slapd.conf and slapd.log files are on the OpenLDAP ftp server as: > ftp://ftp.openldap.org/incoming/idlcache-bug.tar.gz > > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5303) idlcache problem with new entries
by quanah＠zimbra.com 31 Dec '07

31 Dec '07

Full_Name: Quanah Gibson-Mount Version: 2.3.39 OS: NA URL: ftp://ftp.openldap.org/incoming/idlcache-bug.tar.gz Submission from: (NULL) (76.21.80.71) While testing heavy account provisioning using multiple threads to create accounts in an OpenLDAP server, we discovered that the idl cache fails to properly update, making searches for successfully added accounts fail to find them. Setting the idlcachesize to zero resolved the search problem, indicating an issue inside the idl cache code. Zimbra bug is here: http://bugzilla.zimbra.com/show_bug.cgi?id=22933 Description: ============ - OpenLDAP build: openldap-2.3.39 - 20 concurrent threads are ADDing (distinct) entries in a loop under a common base DN. - It seems intermittently upon DB_LOCK_DEADLOCK errors, the integrity of indexes are broken for a period of time even after the ADD returns a good code(err=0). Search filtered on an indexed attribute of the newly ADDed entry cannot be found. If the same query is done again later, it did find the entry. - This seems to happen only after "many" DB_LOCK_DEADLOCK errors. The search failure usually happens after 20 to 80 iterations into the loop, while the deadlock error would start happening since earlier iterations. Notes on info in attached slapd.log: ==================================== 1. The described test started on line 996. 2. Line 25510 shows the ADD Dec 20 14:45:51 phoebe slapd[209]: conn=2235 op=1 ADD dn="uid=a-120-thread-3,ou=people,dc=test-accounts-20071220-143806,dc=ldaptest" 3. Line 25542 shows the ADD was successful Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=1 RESULT tag=105 err=0 text= This entry should contain (among other attributes): objectClass: zimbraAccount zimbraId: be0b628b-b8d1-4fce-99cd-7b7f6864149a 4. Line 25549 - 25550 shows the search on that zimbraId returned 0 entry: Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=2 SRCH base="" scope=2 deref=3 filter="(&(zimbraId=be0b628b-b8d1-4fce-99cd-7b7f6864149a)(objectClass=zimbraAccount))" Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= 5. Later, the same search(as in 3) was attempted. Line 25756 - 25757 shows the same query did find one entry this time: Dec 20 14:48:25 phoebe slapd[209]: conn=2250 op=1 SRCH base="" scope=2 deref=3 filter="(&(zimbraId=be0b628b-b8d1-4fce-99cd-7b7f6864149a)(objectClass=zimbraAccount))" Dec 20 14:48:25 phoebe slapd[209]: conn=2250 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= 6. As shown in the log, there was no MOD or anything on DN dn="uid=a-120-thread-3,ou=people,dc=test-accounts-20071220-143806,dc=ldaptest" between 3 and 4. 7. Other info: - zimbraId is an indexed attribute. see slapd.conf. - Note, the test stops when it encounters the first failed search after a successful create. slapd.conf and slapd.log files are on the OpenLDAP ftp server as: ftp://ftp.openldap.org/incoming/idlcache-bug.tar.gz

1 0

(ITS#5302) Possible leak in slapo-memberof
by ando＠sys-net.it 29 Dec '07

29 Dec '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando slapo-memberof re-injects internal modifications through the overlay stack, in case other overlays need to be processed. This may cause the leaking of saved membership values, since those modifications pass through all related instances of slapo-memberof. Better stored values disposal has been added.

1 0

(ITS#5301) Slapo-memberof cannot be used as global
by ando＠sys-net.it 29 Dec '07

29 Dec '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Basically, because it makes use of be_entry_get_rw(), which is not available for the frontent, and because it can try to modify operational attributes (e.g. the modifiersName), while the frontend does not expect modifications to be SLAP_MOD_INTERNAL that early. A fix is coming. p.

1 0

I find a errorin this function LDAPSearchResults search(LDAPUrl toGet)
by 周建国 28 Dec '07

28 Dec '07

when i use connection pool i run this function search(LDAPUrl toGet),it will appear a error :can not close the connection so i try to correct the bug,it is no problem: LDAPConfigurationReader LDAPConfigurationReader = null; LDAPConfigurationReader=LDAPConfigurationReader.getInstance (); Map hashMap = null; try { hashMap = LDAPConfigurationReader.getConfiguration(); } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } connectionFactory=ConnectionFactory.getInstance(); poolManager=connectionFactory.connection(hashMap); LDAPConnection=connectionFactory.bindConnection (poolManager); LDAPSearchResults searchResults = LDAPConnection.search(LDAPConnection,myUrl ); public static LDAPSearchResults search(LDAPConnection LDAPConnection,LDAPUrl toGet) throws LDAPException { // Get a clone of default search constraints, method alters batchSize return search( LDAPConnection,toGet, null); } public static LDAPSearchResults search(LDAPConnection LDAPConnection,LDAPUrl toGet, LDAPSearchConstraints cons) throws LDAPException { if( Debug.LDAP_DEBUG) { Debug.trace( Debug.apiRequests, "LDAPConnection.search(" + toGet.toString() + ")"); } //LDAPConnection lconn = new LDAPConnection(); LDAPConnection.connect(toGet.getHost(),toGet.getPort()); if( cons == null) { // This is a clone, so we already have our own copy cons = LDAPConnection.getSearchConstraints(); } else { // get our own copy of user's constraints because we modify it cons = (LDAPSearchConstraints)cons.clone(); } cons.setBatchSize(0); // Must wait until all results arrive LDAPSearchResults toReturn = LDAPConnection.search(toGet.getDN(), toGet.getScope(), toGet.getFilter(), toGet.getAttributeArray (), false, cons); //lconn.disconnect(); return toReturn; } -- My MSN:zhoujianguo_leo@hotmail.com i from china shanghai

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