Full_Name: Doug Leavitt Version: HEAD OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.18.43.225)

It seems that slapd is returning success if an unsupported extensible match is given. Probably LDAP_INAPPROPRIATE_MATCHING or maybe LDAP_UNAVAILABLE_CRITICAL_EXTENSION chould be returned. Instead.

Example:

Attempting a search using the MS LDAP_MATCHING_RULE_IN_CHAIN extensible match rule: http://msdn.microsoft.com/en-us/library/aa746475%28VS.85%29.aspx OID: 1.2.840.113556.1.4.194

Should fail since it is currently unsupported by OpenLDAP. Something like: ldapsearch -v -h <server> -D <admin dn> -w <admin pw> -b <base> "memberof:1.2.840.113556.1.4.1941:=cn=ldap_many1,dc=mc,dc=sun,dc=com"

Should return error, but instead returns success with 0 matches.

I believe that the root of the problem is that in servers/slapd/filter.c:

case LDAP_FILTER_EXT: Debug( LDAP_DEBUG_FILTER, "EXTENSIBLE\n", 0, 0, 0 );

err = get_mra( op, ber, &f, text ); if ( err != LDAP_SUCCESS ) { break;

...

...

err is returned with the value LDAP_INAPPROPRIATE_MATCHING

}

assert( f.f_mra != NULL ); break;

default: (void) ber_scanf( ber, "x" ); /* skip the element */ Debug( LDAP_DEBUG_ANY, "get_filter: unknown filter type=%lu\n", f.f_choice, 0, 0 ); f.f_choice = SLAPD_FILTER_COMPUTED; f.f_result = SLAPD_COMPARE_UNDEFINED; break; }

...

...

and will return LDAP_SUCCESS with the following:

if( err != LDAP_SUCCESS && err != SLAPD_DISCONNECT ) { /* ignore error */ *text = NULL; f.f_choice = SLAPD_FILTER_COMPUTED; f.f_result = SLAPD_COMPARE_UNDEFINED; err = LDAP_SUCCESS; }

which will allow the filter to proceed, loosing the error. It seems like the search should fail given an illegal/unsupported extensible filter.