[Date Prev][Date Next]
Re: (ITS#5731) Don't rewrite filter when it is undefined
----- email@example.com wrote:
> On Thu, 09 Oct 2008 23:45:42 +0300, <firstname.lastname@example.org> 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