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

[anibal.caceres@ericsson.com]

Full_Name: Anibal Caceres Hernando
Version: 2.1.25
OS: GNU/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (194.237.142.7)


   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,

   Aníbal.