[Date Prev][Date Next]
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
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
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
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.)