Re: (ITS#5731) Don't rewrite filter when it is undefined

[kouk@noc.uoa.gr]

On Thu, 09 Oct 2008 23:45:42 +0300, <ando@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 fix
> (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 question  
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 current  
(HEAD) behavior is that it is ignored (as false?). This is different from  
the previous behavior where, as I remember, an undefined filter error was  
reported to the client.

Also from my tests with HEAD it seems that when the rwm overlay is present  
the implemented fix's check for an undefined filter will produce a filter  
semantically equivalent to false, "(!(objectClass=*))", which slapd will  
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.

 From the debug log, when searching with (entryUUID=123) without the rwm  
overlay:

   search_candidates: base="ou=myunit,dc=mydomain,dc=gr" (0x00000001)  
scope=2
   => bdb_dn2idl("ou=myunit,dc=mydomain,dc=gr")
   => bdb_filter_candidates
      AND
   => bdb_list_candidates 0xa0
   => bdb_filter_candidates
      OR
   => bdb_list_candidates 0xa1
   => bdb_filter_candidates
      EQUALITY
   => bdb_equality_candidates (objectClass)
   => key_read
   bdb_idl_fetch_key: [b49d1940]
   <= bdb_index_read: failed (-30989)
   <= bdb_equality_candidates: id=0, first=0, last=0
   <= bdb_filter_candidates: id=0 first=0 last=0
   => bdb_filter_candidates
   <= bdb_filter_candidates: id=0 first=0 last=0
   <= bdb_list_candidates: id=0 first=0 last=0
   <= bdb_filter_candidates: id=0 first=0 last=0
   <= bdb_list_candidates: id=0 first=1 last=0
   <= bdb_filter_candidates: id=0 first=1 last=0
   bdb_search_candidates: id=0 first=1 last=0
   bdb_search: no candidates

 From the debug log, when searching with (entryUUID=123) *with* the rwm  
overlay

   search_candidates: base="ou=myunit,dc=mydomain,dc=gr" (0x00000001)  
scope=2
   => bdb_dn2idl("ou=myunit,dc=mydomain,dc=gr")
   => bdb_filter_candidates
      AND
   => bdb_list_candidates 0xa0
   => bdb_filter_candidates
      OR
   => bdb_list_candidates 0xa1
   => bdb_filter_candidates
      EQUALITY
   => bdb_equality_candidates (objectClass)
   => key_read
   bdb_idl_fetch_key: [b49d1940]
   <= bdb_index_read: failed (-30989)
   <= bdb_equality_candidates: id=0, first=0, last=0
   <= bdb_filter_candidates: id=0 first=0 last=0
   => bdb_filter_candidates
      NOT
   <= bdb_filter_candidates: id=-1 first=1 last=1911
   <= bdb_list_candidates: id=-1 first=1 last=1911
   <= bdb_filter_candidates: id=-1 first=1 last=1911
   <= bdb_list_candidates: id=-1 first=1 last=1911
   <= bdb_filter_candidates: id=-1 first=1 last=1911
   bdb_search_candidates: id=-1 first=1 last=1911
   => test_filter
       NOT
   => test_filter
       PRESENT
   => access_allowed: search access to "ou=myunit,dc=mydomain,dc=gr"  
"objectClass" requested
   <= root access granted
   => access_allowed: search access granted by manage(=mwrscxd)
   <= test_filter 6
   <= test_filter 5
   bdb_search: 1 does not match filter
   entry_decode: "uid=someone,ou=myunit,dc=mydomain,dc=gr"
   <= entry_decode(uid=someone,ou=myunit,dc=mydomain,dc=gr)
   => bdb_dn2id("uid=someone,ou=myunit,dc=mydomain,dc=gr")
   <= bdb_dn2id: got id=0x2
   [... repeated for each entry under the base dn ...]


So my question is, is this intended and/or reasonable? My uninformed  
opinion is that it would be better if an error is reported to the client  
when using an undefined filter (as in 2.4.11 without the rwm overlay) but  
that also slapd shouldn't try and match every entry with an undefined  
filter in the case the rwm overlay is applied.