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

[FIXED] (ITS#4140) chain overlay may leak resources and suffer from concurrency issues

I have (almost) entirely reworked the way the chain overlay works.  Now
a set of "known" URIs can be defined, with specific configuration
parameters (e.g. the identity that is used for proxyAuthz and so).  Each
of them gets a specific ldapinfo_t structure that is stored in an AVL
tree and looked up by "normalized" URI.  By "normalized" I mean that the
URI is parsed and rebuilt by considering only the proto/host/port
portion, so it SHOULD always get the same form apart for the case
[OT: URIs in LDAP are case sensitive, but the host portion should not,
because the DNS does not care; what about a unified normalization
criterion for URIs?  I remember we already discussed the issue].  If a
referral pointing to an "unknown" URI is handled, a temporary ldapinfo_t
is created to deal with the referral.  If instructed to do so, the
overlay can add that URI to the cache, otherwise it's trashed after use.
The temporary URI structures inherit the essential properties from a
template that can be configured.  They are always chained anonymously.


overlay		chain
#slapo-chain specific options
#generic slapd-ldap options that build the template
chain-uri	<a single URI>
#slapd-ldap options specific to that URI
chain-uri	<another single URI>
#slapd-ldap options specific to that second URI

One nice feature is that all the configured URIs and the template show
up as children of the overlay entry in back-config, and they can even be
created by back-config.  That was not easy, though, but it seems to work
now.  I haven't tried modifications or deletion (I think delete is
totally disabled) so there might be issues yet.  Please, check the
implementation because every now and then I might have reinvented the
wheel or done obvious things in a cumbersome manner.

I think there remains a slight inconsistency when the configuration is
read from slapd.conf as opposed to the overlay being written via
ldapadd; it lies in the fact that in order to represent the URIs as
slapd-ldap databases I had to malloc a new BackendDB structure for each
newly added URI structure, while when reading from slapd.conf I only
need to malloc the database private data; so that BackendDB is going to
leak as shutdown; not a big deal.

- implement the loop-detection strategy indicated by Howard
- review the chaining control (might lag behind the draft, which expired
by the way; should we rather remove the code?)


Ing. Pierangelo Masarati
Responsabile Open Solution

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