openldap-bugs September 2007

openldap-bugs@openldap.org

33 participants
179 discussions

(ITS#5155) Leak in back-meta when binding as rootdn
by ando＠sys-net.it 26 Sep '07

26 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) back-meta leaks orb_edn after adding be_rootdn_bind() support (ITS#4962) p.

1 0

Re: (ITS#5121) IDL cache issue
by ando＠sys-net.it 26 Sep '07

26 Sep '07

Howard Chu wrote: > ando(a)sys-net.it wrote: >> To reproduce: >> >> - set idlcache >> >> - search one entry, so that the idl gets cached >> >> - delete that entry, so that the idl gets cleared - but head/tail don't >> >> - search another entry so that it gets cached - head/tail are corrupted >> >> I've a fix for this about to come (affects 2.4.5 as well, sigh; not sure >> about re23). > > Coverity shows this patch has introduced a NULL pointer dereference. > @@ -364,6 +381,9 @@ > ee = bdb->bi_idl_lru_tail; > for ( i = 0; i < 10; i++, ee = eprev ) { > eprev = ee->idl_lru_prev; > + if ( eprev == ee ) { > + eprev = NULL; > + } > if ( ee->idl_flags & CACHE_ENTRY_REFERENCED ) { > ee->idl_flags ^= CACHE_ENTRY_REFERENCED; > continue; > > What's the purpose of this change Make sure bi_idl_lru_tail gets set to NULL if purging the cache makes it empty. Perhaps it's an overshoot. > and should you be testing for a NULL > now in the for loop conditions? Yes, I realize I should test for ee != NULL in the for loop. 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#5154) Sequential binds to back-meta cause assertion failiure
by mhardin＠symas.com 26 Sep '07

26 Sep '07

> -----Original Message----- > From: Pierangelo Masarati [mailto:ando@sys-net.it] > Sent: Wednesday, September 26, 2007 2:54 PM > To: mhardin(a)symas.com > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#5154) Sequential binds to back-meta cause assertion > failiure > > mhardin(a)symas.com wrote: > > Full_Name: Matthew Hardin > > Version: 2.3.38 > > OS: N/A > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (12.168.121.2) > > > > > > Multiple binds on the same connection where at least one bind ends up > being [...] > > /* FIXME: in some cases (e.g. unavailable) > > * do not assume it's not candidate; rather > > * mark this as an error to be eventually > > I think the "real" fix should be different: binds should always receive > a fresh connection from meta_back_getconn(), which shouldn't be put > into the cache at all. meta_back_bind() should cache them only in case > of success, otherwise they should be destroyed. This would allow to > remove the need to set a BINDING flag to guarantee connections used for > bind are not shared. I agree that would be a better fix. > In the meanwhile, the solution you propose should be just fine, as it > fills the hole occurring when a bind fails. > > I'll work at that ASAP. Thanks! -Matt Matthew Hardin Symas Corporation- The LDAP Guys http://www.symas.com

1 0

Re: (ITS#5121) IDL cache issue
by hyc＠symas.com 26 Sep '07

26 Sep '07

ando(a)sys-net.it wrote: > To reproduce: > > - set idlcache > > - search one entry, so that the idl gets cached > > - delete that entry, so that the idl gets cleared - but head/tail don't > > - search another entry so that it gets cached - head/tail are corrupted > > I've a fix for this about to come (affects 2.4.5 as well, sigh; not sure > about re23). Coverity shows this patch has introduced a NULL pointer dereference. @@ -364,6 +381,9 @@ ee = bdb->bi_idl_lru_tail; for ( i = 0; i < 10; i++, ee = eprev ) { eprev = ee->idl_lru_prev; + if ( eprev == ee ) { + eprev = NULL; + } if ( ee->idl_flags & CACHE_ENTRY_REFERENCED ) { ee->idl_flags ^= CACHE_ENTRY_REFERENCED; continue; What's the purpose of this change, and should you be testing for a NULL now in the for loop conditions? -- -- 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

Re: (ITS#5154) Sequential binds to back-meta cause assertion failiure
by ando＠sys-net.it 26 Sep '07

26 Sep '07

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.3.38 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.168.121.2) > > > Multiple binds on the same connection where at least one bind ends up being > passed through to a target and where the credentials for that bind are incorrect > will cause back-meta to throw an assertion failure during a subsequent bind. In > this situation back-meta prints the message "slapd: bind.c:229: meta_back_bind: > Assertion `tmpmc == mc' failed". > > Analysis: > In bind.c there is no cleanup of the metaconn structure after a failed bind to a > target database. This is ordinarily not a problem, as most applications perform > an unbind immediately after a failed bind and so fail to trigger this bug. > However, applications such as pam_ldap will perform several binds to as many as > two different identities on the same connection, and the credentials for one of > those identities are routinely incorrect. This bug causes the metaconn structure > from the failed bind to be left in the mi_conninfo.lai_tree avl tree and then > found during the re-insertion of a metaconn structure from a subsequent bind > (approx between lines 209-258 in bind.c), causing the assertion failure and > killing slapd in the process. > > Note: This bug can be exploited as a DOS attack, as the behavior is relatively > easy to reproduce on an unpatched system with a short perl script. > > > Proposed Fix: > The simplest and best fix appears to be to mark the metaconn struct from the > failed bind as tainted. This causes the struct to be deleted in the call to > meta_back_release_conn around line 281. > > The patch is as follows: > > bind.c > *************** > *** 189,194 **** > --- 189,198 ---- > > if ( lerr != LDAP_SUCCESS ) { > rc = rs->sr_err = lerr; > + /* Mark the meta_conn struct as tainted so > + * it'll be freed by meta_conn_back_destroy below */ > + LDAP_BACK_CONN_TAINTED_SET( mc ); > + > /* FIXME: in some cases (e.g. unavailable) > * do not assume it's not candidate; rather > * mark this as an error to be eventually I think the "real" fix should be different: binds should always receive a fresh connection from meta_back_getconn(), which shouldn't be put into the cache at all. meta_back_bind() should cache them only in case of success, otherwise they should be destroyed. This would allow to remove the need to set a BINDING flag to guarantee connections used for bind are not shared. In the meanwhile, the solution you propose should be just fine, as it fills the hole occurring when a bind fails. I'll work at that ASAP. 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

(ITS#5154) Sequential binds to back-meta cause assertion failiure
by mhardin＠symas.com 26 Sep '07

26 Sep '07

Full_Name: Matthew Hardin Version: 2.3.38 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.168.121.2) Multiple binds on the same connection where at least one bind ends up being passed through to a target and where the credentials for that bind are incorrect will cause back-meta to throw an assertion failure during a subsequent bind. In this situation back-meta prints the message "slapd: bind.c:229: meta_back_bind: Assertion `tmpmc == mc' failed". Analysis: In bind.c there is no cleanup of the metaconn structure after a failed bind to a target database. This is ordinarily not a problem, as most applications perform an unbind immediately after a failed bind and so fail to trigger this bug. However, applications such as pam_ldap will perform several binds to as many as two different identities on the same connection, and the credentials for one of those identities are routinely incorrect. This bug causes the metaconn structure from the failed bind to be left in the mi_conninfo.lai_tree avl tree and then found during the re-insertion of a metaconn structure from a subsequent bind (approx between lines 209-258 in bind.c), causing the assertion failure and killing slapd in the process. Note: This bug can be exploited as a DOS attack, as the behavior is relatively easy to reproduce on an unpatched system with a short perl script. Proposed Fix: The simplest and best fix appears to be to mark the metaconn struct from the failed bind as tainted. This causes the struct to be deleted in the call to meta_back_release_conn around line 281. The patch is as follows: bind.c *************** *** 189,194 **** --- 189,198 ---- if ( lerr != LDAP_SUCCESS ) { rc = rs->sr_err = lerr; + /* Mark the meta_conn struct as tainted so + * it'll be freed by meta_conn_back_destroy below */ + LDAP_BACK_CONN_TAINTED_SET( mc ); + /* FIXME: in some cases (e.g. unavailable) * do not assume it's not candidate; rather * mark this as an error to be eventually

1 0

(ITS#5153) Performance of large multi-valued attributes
by hyc＠OpenLDAP.org 24 Sep '07

24 Sep '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc A bit late, but this is just for tracking purposes. HEAD now supports a "sortvals" directive for declaring that specific attributes' values be maintained in sorted order. This allows Compare/Filter operations on attributes with very many values to be completed more efficiently. (From O(n) to O(logn).) Modify operations are also similarly improved.

1 0

Re: (ITS#5152) too much logging
by hyc＠symas.com 24 Sep '07

24 Sep '07

babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3.32 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.11.27) > > > Hello, > > We are having hell of problems in production with # logs getting > generated..almost 4Gig worth of transaction binary/BDB logs in a day(4000 10mb > files). > > No debugging/logging turned in slapd. > > Log rotate scripts is moving the logs to diff location to keep the prod up..but > few times we ran of space and I don't find any clue on minimize and log only for > updated transactions. It seems BDB is recording every read/write(not sure)..I > can't enable Auto_Achieve as need them for recovery. > > Any known issue in the space? How to turn of unwanted logging of BDB? Learn how to use BerkeleyDB. http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/… The ITS is for reporting actual bugs in the software. There is no bug here. This ITS will be closed. -- -- 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

Re: (ITS#5142) and (ITS#5143) Why I think these bugs are important to have fixed.
by quanah＠zimbra.com 24 Sep '07

24 Sep '07

--On Monday, September 24, 2007 3:23 PM +0000 tan7f(a)virginia.edu wrote: > > --Apple-Mail-1--260703270 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=US-ASCII; > delsp=yes; > format=flowed > > Hello OpenLdap Developers, > > I haven't heard anything about the two bugs I've submitted in the > jldap libraries, so I'd like to explain why I feel that these two > issues are important to have fixed. Note that the work on JLDAP is generally done a very different set of developers than most of the OpenLDAP folks, so how soon they'll be addressed I don't know. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#5152) too much logging
by Babu.Suresh＠pacificlife.com 24 Sep '07

24 Sep '07

Guys, Any input is greatly appreciated. Please let me know if you need more details of the issue. Thank you _babu -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: Monday, September 24, 2007 3:30 PM To: Suresh, Babu Subject: Re: (ITS#5152) too much logging *** 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#5152. 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#5152) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#5152) 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=5152 Please remember to retain your issue tracking number (ITS#5152) 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-2006 The OpenLDAP Foundation, All Rights Reserved. ------------------------------------------------------------------------------ The information in this e-mail and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. If you believe that you have received this e-mail in error, please contact the sender immediately and delete the e-mail and all of its attachments. ==============================================================================

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 September 2007