Re: slapd segfaults on bad filter (ITS#855)

[mitya@seismic.geol.msu.ru]

Hello Mat!

mat@voxmobili.com wrote:

> Full_Name: Mat
> Version: 2.0.6
> OS: Linux
> URL:
> Submission from: (NULL) (193.251.34.135)
>
> OpenLDAP 2.0.6, configured with --enable-sql --enable-debug
>
> prompt> /usr/local/libexec/slapd -d 1
> [...]
> slapd starting
>
> The server answers a request correctly if asked for objectClass=* for
> instance.
>
> Now, if we try:
> ldapsearch -b 'o=example,c=com' -D <rootdn> -w <rootpw> 'foo=bar'
> -h127.0.0.1
>
> *** slapd trace:

>
> connection_get(10): got connid=0
> ==>backsql_search(): base='O=EXAMPLE,C=COM', filter='(badfilter)',

It is a known bug, unfortunately I still had no time to address it.. Will
try ASAP.

Note that back-sql crashes usually on REALLY BROKEN filters, i.e. those
that were not successfully parsed by frontend. This is illustrated by above
fragment (frontend returned '(badfilter)' as filter string, and probably
something unusual in parsed structure, which is fairly easy to detect, so
it shouldn't be too difficult to eliminate crashes.

I will try to fix this ASAP, meanwhile you could test back-sql with GOOD
filters ;) - it should handle them pretty well, partially translating into
WHERE clauses

see RFC2254 in doc directory if you experiencing problems with what slapd
treats as GOOD filters

WBW, Dmitry

P.S.  that other, #854, issue is probably unneeded?