Re: OpenLDAP 2.4.7 Bug?

[Philip Guenther <guenther+ldapsoft@sendmail.com>]

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.  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