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.