(ITS#6692) LDAP_INAPPROPRIATE_MATCHING not returned when faced with an unsupported extensible match

[doug.leavitt@oracle.com]

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.