Two searches return different results but they should not. The same searches run as DM give the same result so it is an ACI. It is possibly a problem of rights evaluating the parentid component added to the one_level filter.
It is a regression compare to F27
ldapsearch -LLL -D 'uid=my_user,ou=People,dc=example,dc=com' -w password -b 'ou=People,dc=example,dc=com' -s one "(uid=*)" dn <no returned entry> ldapsearch -LLL -D 'uid=my_user,ou=People,dc=example,dc=com' -w password -b 'ou=People,dc=example,dc=com' -s sub "(uid=*)" dn dn: uid=my_user,ou=People,dc=example,dc=com
possibly related to https://pagure.io/389-ds-base/issue/49372
master
testcase attached
Results differ
Same result expected
<img alt="ticket49617_test.py" src="/389-ds-base/issue/raw/files/b3e4e52b4c150a2866a839fb2c797a4195f3aa2ed1c2de5454879b229bf860a3-ticket49617_test.py" />
Metadata Update from @tbordaz: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None
I think this is an effect of #49372. with the patch the optimised, rewritten filter is set to the pblock and used for aci evaluation whereas before the original filter was used
The issue is a blocker for FreeIPA on Fedora 28, see https://pagure.io/freeipa/issue/7466#comment-502338
<img alt="0001-Ticket-49617-SRCH-results-differ-from-one_level-to-s.patch" src="/389-ds-base/issue/raw/files/0333e55bdd465cdc8a860ae2e2415ba52ced057609e7ae737f66777ef8e5dc4f-0001-Ticket-49617-SRCH-results-differ-from-one_level-to-s.patch" />
this patch passes the ticket test and the filter test suites
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4.0
@lkrispen patch looks good, it is ready to merge?
Metadata Update from @mreynolds: - Issue assigned to lkrispen
@lkrispen - is this patch still applicable? Since we backed out the filter optimization fix is this bug still present?
the test case provided by Thierry passes on master, so backing out filter optimization makes the patch obsolete.
But we should probably commit the test case to ensure it will work one we reenable filter opt
I agree, we should add a test for this. Could we add the test to the filter optimisation suite, since that exists to highlight if issues arise in the process of optimising?
I can not reproduce that bug on master (d318d06) so it is fixed. Closing it.
Metadata Update from @tbordaz: - Issue close_status updated to: duplicate - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2676
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: duplicate)
Login to comment on this ticket.