On upgrading to 2.4.2alpha I ran into an issue where a SLAPI ACL
failed where it had not appeared to before. For the purpose of
this discussion assume that the plugin just returns the boolean
value of SLAPI_REQUESTOR_ISROOT (although of course the actual
implementation is somewhat more involved).
The problem appeared to be that slap_read_controls() was calling
slap_send_search_entry() with a NULL backend.
slap_send_search_entry() would then eventually wind up in
access_allowed_mask() which invokes the following code:
if ( op->o_bd == NULL ) {
op->o_bd = LDAP_STAILQ_FIRST( &backendDB );
be_null = 1;
#ifdef LDAP_DEVEL
/*
* FIXME: experimental; use first backend rules
* iff there is no global_acl (ITS#3100) */
if ( frontendDB->be_acl != NULL ) {
op->o_bd = frontendDB;
}
#endif /* LDAP_DEVEL */
}
assert( op->o_bd != NULL );
This probably worked once but now the order of backends is such
that the configuration backend is first and in our deployment
it did not have a root DN specified. As such in spite of the
fact that the read-back was being done by an internal SLAPI op
running as root (which succeeded) read authorization was denied.
For our application (which uses the global SLAPI overlay to call
ACL plugins) enabling LDAP_DEVEL fixed this.
So:
(a) should we just uncomment LDAP_DEVEL or
(b) should slap_read_controls() set the backend to something other
than NULL?
cheers,
-- Luke
--
