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

Re: OpenLDAP 2.4.7 Bug?


On Dec 27, 2007, at 10:26 AM, Philip Guenther wrote:

On Thu, 27 Dec 2007, Dieter Kluenter wrote:
"Allan E. Johannesen" <aej@WPI.EDU> writes:
...
In a program, which had constructed the ** due to a missing first name, it also was found to break the connection to the server...

CCC5:~> ldapsearch '(cn=** VERNON-GERSTENFELD*)' 

[...]
There should be only one asterisk and no space after a asterisk. See
rfc 4515, String representation on search filters.

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.

One can argue that the LDAP ASN.1 and the LDAP filter ABNF should have size constraints on substring values. I consider it a minor bug in specification which should be fixed.

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

-- Kurt


The relevant grammar terms are:

     filter         = LPAREN filtercomp RPAREN
     filtercomp     = and / or / not / item
     item           = simple / present / substring / extensible
     substring      = attr EQUALS [initial] any [final]
     any            = ASTERISK *(assertionvalue ASTERISK)
     assertionvalue = valueencoding
     valueencoding  = 0*(normal / escaped)
     normal         = UTF1SUBSET / UTFMB
     UTF1SUBSET     = %x01-27 / %x2B-5B / %x5D-7F

I.e., it's a substring match with no 'initial', no 'final', and two 'assertionvalue' parts, the first of which is empty (a 'valueencoding' can be zero length) and the second of which is " VERNON-GERSTENFELD".


So, if the text form of the filter is legal, what's breaking? Either the client is sending bad BER or the server is refusing good BER. It looks to me like the latter: the protocol's ASN.1 says that an 'any' substring is an OCTET STRING, which can be zero length, but the substring parser in slapd doesn't accept that: in get_ssa() it treats a zero length substring as an error:
if ( value.bv_val == NULL || value.bv_len == 0 ) {
rc = LDAP_INVALID_SYNTAX;
goto return_error;
}


I suggest that Allan file an ITS...


Philip Guenther