Re: (ITS#5121) IDL cache issue
by ando＠sys-net.it
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
---------------------------------------
15 years, 8 months
RE: (ITS#5154) Sequential binds to back-meta cause assertion failiure
by mhardin＠symas.com
> -----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
15 years, 8 months
Re: (ITS#5121) IDL cache issue
by hyc＠symas.com
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/
15 years, 8 months
Re: (ITS#5154) Sequential binds to back-meta cause assertion failiure
by ando＠sys-net.it
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
---------------------------------------
15 years, 8 months
(ITS#5154) Sequential binds to back-meta cause assertion failiure
by mhardin＠symas.com
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
15 years, 8 months
(ITS#5153) Performance of large multi-valued attributes
by hyc＠OpenLDAP.org
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.
15 years, 8 months
Re: (ITS#5152) too much logging
by hyc＠symas.com
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/transap...
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/
15 years, 8 months
Re: (ITS#5142) and (ITS#5143) Why I think these bugs are important to have fixed.
by quanah＠zimbra.com
--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
15 years, 8 months
RE: (ITS#5152) too much logging
by Babu.Suresh＠pacificlife.com
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.
==============================================================================
15 years, 8 months
