meta backend returns error to client on filter decoding errors (ITS#2977)

[aleksander.adamowski@altkom.pl]

Full_Name: Aleksander Adamowski
Version: 2.1.25
OS: Linux 2.4.22 - Fedora Core 1
URL: http://www.openldap.org/lists/openldap-software/200402/msg00357.html
Submission from: (NULL) (157.25.5.68)


The meta backend returns an error code to the client if there is a filter
decoding error (e.g. filter is malformed).

According to Pierangelo Masarati this violates RFC; bdb backend for example
returns success code and an empty result.

See this thread on OpenLDAP-software mailing list:
http://www.openldap.org/lists/openldap-software/200402/msg00592.html

This behaviour of meta backend causes problems e.g. with Courier mail server
which cannot operate properly if meta backend is used.

See http://www.openldap.org/lists/openldap-software/200402/msg00357.html for an
example of query which is handled correctly by bdb backend and incorrectly by
meta backend. The filter shown there is incorrectly decoded (extracted from
slapd logs); the original filter was (!(source=*)) and this should be used in
testing.

Reproduction:

I'm testing this in a setup where bdb backend listens on port 389 and meta
backend listens on port 390, forwarding all queries to the bdb backend. Correct
queries on existing attributes give the same results on both ports, 389 and
390.

Invalid queries differ in the following way:

When I execute the following command, I get all the entries from directory,
which is a correct outcome:

ldapsearch -x -H "ldap://localhost:389"; '(!(source=*))'

The result code is 0 (success):

# search result
search: 2
result: 0 Success

# numResponses: 561
# numEntries: 560


When I execute the following command, I get an error response:

ldapsearch -x -H "ldap://localhost:390"; '(!(source=*))'

# search result
search: 2
result: 32 No such object

# numResponses: 1