[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#4140) chain overlay may leak resources and suffer from concurrency issues



On Thu, 2005-11-03 at 21:52 +0000, hyc@symas.com wrote:
> ando@sys-net.it wrote:
> > Full_Name: Pierangelo Masarati
> > Version: HEAD, re23
> > OS: irrelevant
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (81.72.89.40)
> > Submitted by: ando
> >
> >
> > In some cases, the chain overlay uses an automatic ldapinfo structure, which is
> > a copy of the original one except for the url.  This results in (at least)
> > leaking connections in the connection tree; it may also result in a corrupted
> > AVL tree and even worse, because mutex locking occurs on copies of the mutexes
> > and so.
> >   
> 
> Ugh. We need to separate out the per-URL info from the overall backend 
> configuration so we can safely manage multiple URLs in back-ldap.

My analysis needs some extra work.

- first of all, the current code does set op->o_do_not_cache; however,
as far as I understand, this only prevents caching of authenticated
connections, the anonymous connection is still shared and the issue
persists.

- second, when the URI is extracted from the referral, we shouldn't
really try to find a way to cache that single anonymous entry, nor the
others, because there's no guarantee that we will ever contact the same
host.  In this case, either

1) we use separate temporary AVL trees when the URI is extracted from
the referral, and we destroy them as soon as the referral chasing is
over (another approach would be to pass yet another flag that instructs
slapd-ldap to not cache the anonymous connection at all), or,

2) since it's reasonable that the URIs are picked from a limited set of
potential values, we use different caches recognized based on the URI.
In this case, the URI, possibly the ACL bindconf info, and the
connection AVL should be in one malloc'ed structure, the chain overlay
should keep a stack of these, and the ldapinfo structure should be
attached the most appropriate of them based on the URI that is selected.

I don't know if (2) is worth the effort, though.




Ing. Pierangelo Masarati
Responsabile Open Solution

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------