----- kouk(a)noc.uoa.gr wrote:
On Thu, 09 Oct 2008 23:45:42 +0300, <ando(a)sys-net.it> wrote:
> The bug is confirmed; the proposed fix is incorrect, since it only
> addresses the case of a(n undefined) simple filter. A more complete
> (see also ITS#5732) is in HEAD, please test. p.
OK, I tested it and indeed it doesn't crash anymore. But I have a
regarding the fix in HEAD. When an undefined filter is supplied by the
client, what is the intended behavior? From what I can tell the
(HEAD) behavior is that it is ignored (as false?). This is different
the previous behavior where, as I remember, an undefined filter error
reported to the client.
AFAIK, the correct behavior is to ignore the filter if it is undefined. Nothing has to be
reported to the client. If it occurred earlier, it was an error.
Also from my tests with HEAD it seems that when the rwm overlay is
the implemented fix's check for an undefined filter will produce a
semantically equivalent to false, "(!(objectClass=*))", which slapd
then procede to match against every entry under the base DN. This is
different than what happens in HEAD (and in 2.4.11) without the rwm
overlay, which is that the entries aren't even considered.
When the filter is undefined, it is ignored. In fact, if a filter is
"(|(cn=*)(foo=bar))" and attribute "foo" does not exist, the filter
reduces to "(cn=*)". However, when the remapped filter needs to be passed to
ldap_search() in string form, an undefined filter needs to be rewritten in LDAP form. I
decided to rework it into "(!(objectClass=*))" just because it was easier. A
better solution would probably have been to handle it along the above lines. Call it
laziness, if you like. Feel free to propose a better solution. Better if you provide a
patch, though :)
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497