(ITS#4018) more general approach to detection of authorizing backend needed in back-ldap

[ando@sys-net.it]

Full_Name: Pierangelo Masarati
Version: HEAD,re23
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.74.43.82)
Submitted by: ando


Code derived from back-ldap, or using it as an internal database, may need a
more general approach to determine if that instance of the ldap-backend was the
authorizing backend.  Currently, a pointer to the authorizing backend as seen by
the frontend is added to the connection structure in c_authz_backend; the field
c_authz_backend->be_private is tested to check if a backend was the
authz_backend.  This may erroneously fail, or give false positives in two
different cases:

1) when overlays are used, it may point to something different from the
be_private of the underlying back-ldap instance that is temporarily stored in
the be_private field of the BackendDB that is being compared with the
c_authz_backend

2) when back-ldap is internally used in another piece of code (for instance,
this occurs in the chain overlay, and may well occur in other cases because
having an internal instance of a database is becoming a common technique in
custom code development; see the slapo-translucent, the slapo-pcache, and more)

This issue is by no means specific to back-ldap; other overlays that implement
the be_bind hook may need it; currently, only back-ldap may incur into this
issue.

By now I fixed this issue in this manner:

a) I added a c_authz_cookie field to the connection structure; this is not dealt
with by the frontend, it's just cleared __before__ calling the appropriate
database be_bind function.

b) I added a macro SLAP_IS_AUTHZ_BACKEND(op) that takes an operation structure
and, after sanity checks, checks if either

        op->o_bd->be_private == op->o_conn->c_authz_backend->be_private

or

        op->o_bd->be_private == op->o_conn->c_authz_cookie

It is the responsibility of the custom code implementor to set
op->o_conn->c_authz_cookie to the be_private of the BackendDB structure that
actually authorized the connection.

I understand this solution may be less than optimal, but it works in all the
cases I could envisage.  An approach with a higher level of abstraction could be
designed if more complex cases occur.  I committed the fix to HEAD, as it does
not impact the code in any part, and, if c_authz_cookie is not set, it provides
nothing more and nothing less than the original behavior.

p.