[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP 2.4.7 Bug?

On Thu, 27 Dec 2007, Howard Chu wrote:
Kurt Zeilenga wrote:
On Dec 27, 2007, at 10:26 AM, Philip Guenther wrote:
Umm, no. That filter matches the grammar in RFC 4515. 

Note that there is no way one can represent an empty initial or empty
final substrings.  That's because empty substrings are nonsense.  The
filter (cn=**) is invalid as it represents an empty initial, an empty
any, and an empty final.  slapd(8) correctly errors on receipt of any
empty substring.

If this has always been an error, then I'm surprised the restriction isn't mentioned at all---not even in prose---in either RFC 2251 or RFC 4511. Note that RFC 4517 _does_ ban empty 'any' parts in SubstringAssertion, so the issue was at least thought about in that context.

I would also contest the claim that empty substrings are nonsense. They may clearly be useless, but they are not logically inconsistent. Indeed, a server can trivially 'support' them by simply ignoring them whenever they appear. The lack of a restriction against them in the specs would imply that a server that fails to do so is non-compliant.

That said, if most servers throw an error on empty substrings, then clients can't send them and expect it to reliably work and (as you suggest) they should be removed from the protocol when it is revised. Perhaps an errata should be filed now.


Size constraints would also fix this stupid wart in the grammar:

  Note that although both the <substring> and <present> productions in
  the grammar above can produce the "attr=*" construct, this construct
  is used only to denote a presence filter.

Doing _that_ would require more than size constraints on 'any'. To keep 'substring' from matching "attr=*" you need to make substring something like:
substring = attr EQUALS substringpat
substringpat = initial ASTERISK [any] [final]
/ ASTERISK any [final]
/ ASTERISK final
initial = substringvalue
any = 1*(substringvalue ASTERISK)
final = substringvalue
substringvalue = 1*(normal / escaped)

(I.e., break out the three cases of non-empty initial, any, and final.)


IMO, the bug is in ldapsearch(1).  It should reject a filter with
empty substrings.


You mean it's a bug in libldap, as that's what's doing the parsing.


I guess Allan needs to go ahead and change the program that's generating these searches to explicitly test for empty parts and suppress them when building the filter. (He should probably also check that it's doing RFC 2254 encoding of the values that it's inserting in the filters while he's at it. It's no good to catch an empty first-name field if the user can ask for a first-name of "*" and generate "(cn=***lastname*)". Generating filters isn't as trivial as one might wish.)


Philip Guenther