slapd 2.0.7 rejects correct filters (ITS#986)

[afm@othello.ch]

Full_Name: Andreas Mueller
Version: 2.0.7
OS: Solaris 2.6, others affected as well
URL: 
Submission from: (NULL) (193.5.25.24)


slapd 2.0.7 rejects all filters containing the <= or >= operators.

There is no indication to the client that the search operation has failed,
it simply returns nothing. Only the server log contains a record about the
query, with the search filter replaced by the string '(badfilter)'.

When get_filter (in filter.c) scans the filter definition, it first
determines the operator (from the tag) and then scans for two octet
strings. This is done in get_ava, in the same function, value_normalize
is used to determine appropriateness of the operator. And value_normalize
determines that there is no matching rule (value.c, line 86). This is
caused by the sat_sorting field not being set by any default, and can
be fixed by modifying the core.schema definition of the 'name' objectclass
from

attributetype ( 2.5.4.41 NAME 'name'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

to

attributetype ( 2.5.4.41 NAME 'name'
        EQUALITY caseIgnoreMatch
        ORDERING caseIgnoreOrderingMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

(note the missing declaration of the ORDERING matching rule). Surprisingly
(to me), no similar problem appears for approximate matching. Is there some
initialization missing for the sat_ordering field? 

There are some remaining issues here:
0. shouldn't there be some default matching rules from which all attribute
   types inherit, even if no definition is found in the core.schema?
1. although get_ava concludes that the filter is bad, no ldap error is
   returned to the client, there should be some inapropriate operation
   or unwilling to perform error.
2. the functions prepare error message texts, but it seems they are never
actually
   displayed anywhere, or am I missing something?
3. how about a function to dump the database of attribute types and object
   classes after it has been read, so that debugging schema definitions would
   become eazier? Something like how named reacts to SIGINT.

But in any event, please keep up the good work.