Re: back-meta: possible bug in the handling of the candidate targets (ITS#2935)

[ando@sys-net.it]

anibal.caceres@ericsson.com wrote:

>   I'm using OpenLDAP 2.1.25, and I've detected a strange behaviour in the meta
>backend: in some LDAP "search" operations it takes as candidates to send the
>operation some targets whose naming context has nothing to do with the base of
>the "search", then it sends to them the "search" operation, but they shouldn't
>have to receive it. The cause for this is in the "bind" operation previous to
>the "search" one: this operation marks its candidate targets, and this targets
>still remain marked for the next operation: the "search" one.
>   I think the reason for all this is in the function meta_back_getconn() from
>the conn.c source file in the meta backend: This function, depending on its
>argument op_type marks the different candidate targets for each LDAP operation.
>In the "search" operation case, op_type=META_OP_ALLOW_MULTIPLE, and in this case
>meta_back_getconn() does the following "for" loop:
>
>       for ( i = 0; i < li->ntargets; i++ ) {
>           if ( i == cached
>       || meta_back_is_candidate( &li->targets[ i ]->suffix, ndn ) ) {
>
>               /*
>                * The target is activated; if needed, it is
>                * also init'd
>                */
>               int lerr = init_one_conn( conn, op,
>                       li->targets[ i ],
>                       &lc->conns[ i ] );
>               if ( lerr != LDAP_SUCCESS ) {
>                                 /*
>                    * FIXME: in case one target cannot
>                    * be init'd, should the other ones
>                    * be tried?
>                    */
>                   ( void )meta_clear_one_candidate( &lc->conns[ i ], 1 );
>                   err = lerr;
>                   continue;
>               }
>           }
>       }
>     This loop checks for every target if it is a candidate, and if it is, it is
>marked as candidate, but if the target is not a candidate, then nothing is
>done... but the list of targets is the same as in the previous LDAP operation,
>so the candidates marked for that one remain marked, even if they are not good
>candidates for the "search" operation... Then I think the "if " in the "for"
>loop must be followed by an "else" where the candidate is unmarked if it was
>marked before (I supposse the meta_clear_one candidate() function can be used
>for this).
>   So, I would know what do you think about this, am I right?, or am I missing
>something somewhere?
>   Any kind of help would be appreciated. Thank you very much.
>   Kind regards,
>  
>
The code has been heavily reworked in HEAD; now the array of candidates 
is unique per operation, and the selection process does its best to 
resolve ambiguities when more targets could serve the same operation 
requiring a unique object by performing an internal search.

In any case, thanks for reporting.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it



    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497