[Fedora-directory-devel] Please review (Revised): [Bug 464854] ldapsearch with size limit (-z) doesn't work with OR filter and range search

[Noriko Hosoi]

[Bug 464854] ldapsearch with size limit (-z) doesn't work with OR filter 
and range search

https://bugzilla.redhat.com/show_bug.cgi?id=464854
>  [Description of Problem]
>  If sizelimit is specified (e.g., -z 5) in ldapsearch, the filter 
>  including a range search does not return expected entries even if 
>  entries matches the filter.
>
>  How to reproduce the problem:
>  Create a test ldif file with dbgen.pl
>  $ dbgen.pl -o /path/to/example10k.ldif -n 10000
>  Import it
>  $ ldif2db -n userRoot -i /path/to/example10k.ldif
>  Start the server
>  $ start-slapd
>
>  Run the following command
>  $ ldapsearch -D 'cn=Directory Manager' -w <pw> -b
> "dc=example,dc=com"
>  "(&(l=Boston)(|(ou=Payroll)(ou=Accounting))(roomNumber>=9700))" dn 
>  roomNumber l ou
>  It returns 7 entries.
>
>  $ ldapsearch -D 'cn=Directory Manager' -w <pw> -b
> "dc=example,dc=com" 
>  -z 5
>  "(&(l=Boston)(|(ou=Payroll)(ou=Accounting))(roomNumber>=9700))" dn 
>  roomNumber l ou
>  It returns no entries.  This entry count could be random from 0 to 5.
>  Expected result: returns 5 entries
>
>  Problem description:
>  SIZELIMIT is checked in index_range_read to eliminate the unnecessary 
>  data
>  retrieval.  But when the filter contains a range search which is 
>  connected by
>  AND, then we should not do sizelimit.  There was a bug in the function 
>  which
>  sets is_and.  The flag should have been cleared only when the function 
>  set it
>  to 1.  Instead, it was cleared each time the function is called.  It let
>  index_range_read stop reading when it reaches sizelimit even though it 
>  should
>  not have. 
[Revised proposed fix]

Created an attachment (id=328591)
 --> (https://bugzilla.redhat.com/attachment.cgi?id=328591)
Revised: cvs diff ldapserver/ldap/servers/slapd/back-ldbm/filterindex.c

Thanks to Nathan for pointing out the flaw in my previous proposal.  It had a
bug in the nested AND case.  Inner AND was clearing "is_and", which should not
have.  It was fixed in this new proposal.