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.