Description of problem:

The search results are different between older version of RHDS10 and RHDS11 when non-existent entry is specified as BaseDN like

  (RHDS10)
  $ ldapsearch -LLL-x -D "uid=testuser1,ou=People,dc=ad,dc=example,dc=com" -W -b "ou=dummy,dc=ad,dc=example,dc=com"
  $ echo $?
  32

  (RHDS11)
  $ ldapsearch -LLL-x -D "uid=testuser1,ou=People,dc=ad,dc=example,dc=com" -W -b "ou=dummy,dc=ad,dc=example,dc=com"
  $ echo $?
  0

  
The customer is requesting to provide a way to get RDHS11 to work in the old way of RHDS10 (i.e. return 32(NO_SUCH_OBJECT) instead of 0(SUCCESS)).
I have found the workaround that adds the follwoing aci attritbute to the root suffix.

  aci: (targetattr="*")(version 3.0; acl "Read/Write permission for all users"; allow (read,write) userdn="ldap:///all";)

However, it won't work properly if specifying read and search.

  aci: (targetattr="*")(version 3.0; acl "Read/Search permission for all users"; allow (read,search) userdn="ldap:///all";)


Why does “write” permission change ns-slapd’s behavior on search operations?
Is this dangerous from a security point of view?


Version-Release number of selected component (if applicable):

- Red Hat Enterprise Linux 8
- RHDS11
- 389-ds-base-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64


How reproducible:

  Always


Steps to Reproduce:

(Test for read and write permissions)
1. Bind as non-root DN and search an entry under non-existing subtree(i.e. ou=dummy) with ldapsearch.

  $ ldapsearch -LLL -x -D "uid=testuser1,ou=People,dc=ad,dc=example,dc=com" -W -b "ou=dummy,dc=ad,dc=example,dc=com"
  $ echo $?

2. To grant all users ad admin, add an ACI attribute to root suffix(i.e. dc=ad,dc=example,dc=com)

  $ ldapmodify -x -D "cn=Directory Manager" -W -f add-aci.ldif

  -- add-aci.ldif --
  dn: dc=ad,dc=example,dc=com
  changetype: modify
  add: aci
  aci: (targetattr="*")(version 3.0; acl "Read/Write permission for all users” ; allow (read,write) userdn="ldap:///all";)

3. Be sure ldapsearch's return code.

  $ ldapsearch -LLL -x -D "uid=testuser1,ou=People,dc=ad,dc=example,dc=com" -W -b "ou=dummy,dc=ad,dc=example,dc=com"
  $ echo $?


(Test for read and search permissions)
1. Delete the mention-above ACI

  $ sed "s/add:/delete:/g" add-aci.ldif | ldapmodify -x -D "cn=Directory Manager" -W 

2. Add another ACI attribute to root suffix

  $ ldapmodify -x -D "cn=Directory Manager" -W -f add-aci2.ldif

  -- add-aci2.ldif --
  dn: dc=ad,dc=example,dc=com
  changetype: modify
  add: aci
  aci: (targetattr="*")(version 3.0; acl "Read/Search permission for all users” ; allow (read,search) userdn="ldap:///all";)

3. Be sure ldapsearch's return code

  $ ldapsearch -LLL -x -D "uid=testuser1,ou=People,dc=ad,dc=example,dc=com" -W -b "ou=dummy,dc=ad,dc=example,dc=com"
  $ echo $?


Actual results:

RHDS11 returns 0 if binding as non-root DN.

  $ ldapsearch -LLL -x -D "uid=testuser1,ou=People,dc=ad,dc=example,dc=com" -W -b "ou=dummy,dc=ad,dc=example,dc=com"
  $ echo $?
  0


Expected results:

RHDS11 returns 32 if binding as non-root DN.

  $ ldapsearch -LLL -x -D "uid=testuser1,ou=People,dc=ad,dc=example,dc=com" -W -b "ou=dummy,dc=ad,dc=example,dc=com"
  $ echo $?
  32


Additional info:

### Analysis

The behavior of RHDS10 and 11 has changed after fixing the security problem.

  https://bugzilla.redhat.com/show_bug.cgi?id=1347760
  https://access.redhat.com/security/cve/CVE-2016-4992


I found the following lines that determine if the user and ACL match in acl__resource_match_aci().
And the comment indicates that it requires `write` for modrdn operation.


  -- ldap/servers/plugins/acl/acl.c in 389-ds-base --
  static int
  acl__resource_match_aci(Acl_PBlock *aclpb, aci_t *aci, int skip_attrEval, int *a_matched)
  {
  ...
 
      if (!attr_matched_in_targetattrfilters) { # case of "targetattr=XXX"
 
          /* match target attr */
          if ((c_attrEval) &&
              (aci->aci_type & ACI_TARGET_ATTR)) {
 
  ...
 
              } else if (aci_right & SLAPI_ACL_WRITE &&                            ***
                         (aci->aci_type & ACI_TARGET_ATTR) &&                      ***
                         !(c_attrEval) &&                                          ***
                         (aci->aci_type & ACI_HAS_ALLOW_RULE)) {
                  /* We need to handle modrdn operation.  Modrdn doesn't
              ** change any attrs but changes the RDN and so (attr=NULL).
              ** Here we found an acl which has a targetattr but
              ** the resource doesn't need one. In that case, we should
              ** consider this acl.
              ** the opposite is true if it is a deny rule, only a deny without
              ** any targetattr should deny modrdn
              ** default: matches = ACL_TRUE;
              */


Why does 389-ds need `write` to match user to the ACI in the case of targetattr rule?