[Fedora-directory-devel] Please review (Revised): [Bug 464854] ldapsearch with size limit (-z) doesn't work with OR filter and range search
Noriko Hosoi
nhosoi at redhat.com
Fri Jan 9 21:11:08 UTC 2009
[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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3250 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20090109/bc90621f/attachment.bin>
More information about the Fedora-directory-devel
mailing list