Please provide your acis.

At the Toplevel (i have stripped some ou's in the ticket, but there are no other aci on the way to ou=users (can provide the full dn if that would be to any help)):
{{{
(targetattr = "memberUid || uid || uidNumber || gidNumber || homeDirectory || gecos || objectClass || cn || givenName || sn || loginShell || afshomedirectory || macaddress || authAuthority") (version 3.0;acl "Anonymous access from XXX.XXX.";allow (read,compare,search)(userdn = "ldap:///anyone") and (ip="XXX.XXX..*");)
}}}
If i add uniquemember to that aci, the OR statement in the filter works.

The behaviour in 1.2.11.15-22 is correct and was broken before.

The RHDS documentation says in
13.3.3.3. Rights Required for LDAP Operations
Searching for entries:

Grant search permission on each attribute type used in the search filter.
Grant read permission on attribute types used in the entry.

This was not enforced in previous releases and could be used to guess values of attributes without read access to them.

Search permissions should be enforced. But they should be enforced for each attribute separately. Search for a attribute that I do not have search rights for should be replaced by false in the search string before the search is executed.

As is is now we have to have an ACL that gives everyone search rights to all attributes. We can't change the search strings for all possible clients. Many don't even have configurable search strings!

If we have an ACL that grants search rights for all clients for all attributes we have a security problem as values can be guessed even if we do not have read rights. This is not good.

If you still say that values can be guessed if I can have attributes in a search string that I do not have search right to (even if search for just that attribute is denied) please give an example for how that could happen!

Replying to [comment:5 pantzer]:

Search permissions should be enforced. But they should be enforced for each attribute separately. Search for a attribute that I do not have search rights for should be replaced by false in the search string before the search is executed.

It is not as simple as that. Acis are evaluated after the search is executed and the candidate listz is determined. It cannot be done before, because the set of applicable acis depends on the entry itself and its location in the tree.

If you still say that values can be guessed if I can have attributes in a search string that I do not have search right to (even if search for just that attribute is denied) please give an example for how that could happen!

After the candidate list is built based on the search filter, for each candidate entry the
- search filter is verified and
- access control is verifies.
For AND and OR filters in the current implementation this is done independently and in prvious releases access was granted if search rights for at least one filter attribut existed - this allowed to guess values if only the filter component of an attribute without access matched.
I will not go into further details describing how to exploit this.

There might be an other solution, which would require reworking the process of filter usage, verification and access control evaluation, but would require a major change.
The current fix is compliant with tehe specification.

I have created ticket 47576 for future improvement, will close this for now

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/893

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.