If you use the userattr keyword in conjunction with all or add permissions, you might find that the behavior of the server is not what you expect. Typically, when a new entry is created in the directory, Directory Server evaluates access rights on the entry being created, and not on the parent entry. However, for ACIs that use the userattr keyword, this behavior could create a security hole, and the server’s normal behavior is modified to avoid it.
Consider the following example:
aci: (target="ldap:///dc=example,dc=com")(targetattr="*") (version 3.0; acl "manager-write"; allow (all) userattr = "manager#USERDN";)
This ACI grants managers all rights on the entries of employees that report to them. However, because access rights are evaluated on the entry being created, this type of ACI would also allow any employee to create an entry in which the manager attribute is set to their own DN. For example, disgruntled employee Joe (cn=Joe,ou=eng,dc=example,dc=com), might want to create an entry in the Human Resources branch of the tree, to use (or misuse) the privileges granted to Human Resources employees.
He could do this by creating the following entry:
dn: cn= Trojan Horse,ou=Human Resources,dc=example,dc=com objectclass: top ... cn: Trojan Horse manager: cn=Joe,ou=eng,dc=example,dc=com
To avoid this type of security threat, the ACI evaluation process does not grant add permission at level 0, that is, to the entry itself. You can, however, use the parent keyword to grant add rights below existing entries. You must specify the number of levels below the parent for add rights. For example, the following ACI allows child entries to be added to any entry in the dc=example,dc=com that has a manager attribute that matches the bind DN:
aci: (target="ldap:///dc=example,dc=com")(targetattr="*") (version 3.0; acl "parent-access"; allow (add) userattr = "parent[0,1].manager#USERDN";)
This ACI ensures that add permission is granted only to users whose bind DN matches the manager attribute of the parent entry.