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

(ITS#3519) back-ldap/back-meta controls forwarding issues

Full_Name: Pierangelo Masarati
Version: HEAD, 2.2 (2.1?)
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (
Submitted by: ando

This report adresses 2 problems:

1) frontend mucking with ldclt_iscritical
2) erroneous proxying of controls by back-meta

1) back-ldap proxies operations using ldap_*_ext() calls and passing op->o_ctrls
as server controls; back-meta proxies controls in a different (and erroneous)
manner, see point (2)), but uses the same data, so suffers from the same
problem.  In op->o_ctrls the ldctl_iscritical flag is mucked by the frontend to
bypass backend_check_controls() for certain controls.

2) back-meta erroneously proxies controls by passing op->o_ctrls via 
ldap_set_options(LDAP_OPT_SERVER_CONTROLS) when a connection is established. 
This is wrong for two reasons: a) controls may (and do) change for each
operation, while connections are being reused, so only controls known at bind
(even if occurring later on because the real bind was anonymous) are passed, and
the others are ignored; b) this means that anonymous binds to serve anonymous
operations are attempted with the op->o_ctrls controls originally requested for
another operation, which may be incompatible with bind itself (e.g. manageDSAit,
or others).

Problem (2) has been fixed in HEAD (please test), while provisions to solve
problem (1) should be already in place; after recent improvements to run-time
control registration, the kludge about controls checking should not be required
any more.
See this whole thread
<http://www.openldap.org/lists/openldap-devel/200501/msg00080.html> for
discussion of details.