Re: ITS#3100 and acl.c

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 09:36 PM 6/15/2006, Luke Howard wrote:

>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

I've fixed this in HEAD.  There is likely other code that
was behind LDAP_DEVEL that now shouldn't be.  That is, if
it's expected to be available in 2.4, it now shouldn't be
behind LDAP_DEVEL.

>(b) should slap_read_controls() set the backend to something other
>than NULL?
>
>cheers,
>
>-- Luke
>
>--