On Tue, Dec 02, 2008 at 03:30:27PM +0000, Andrew Findlay wrote:
The basic idea is to restrict what can be created in each part of the DIT. Suppose you have a node called cn=people,dc=example,dc=org and you want to make sure that all nodes under it describe people. You might write rules like this:
access to dn.exact="cn=people,dc=example,dc=org" attrs=children by dn.exact="cn=admin,cn=people,dc=example,dc=org" write by * read
access to dn.onelevel="cn=people,dc=example,dc=org" filter="(objectClass=inetOrgPerson)" by dn.exact="cn=admin,cn=people,dc=example,dc=org" write by * read
I have used rules of this sort in the past, but ITS#4556 suggests that there are cases where they do not work. See recent discussion: http://www.openldap.org/lists/openldap-devel/200811/msg00014.html
I have now done some more testing on this. Every version of OpenLDAP that I tested (2.3.27 2.4.11 and some recent versions of HEAD) will work with the rules above.
The problem mentioned in ITS#4556 comes up if you grant write access to the 'entry' pseudo-attribute separately. All versions up to 2.4.12 will allow *any* entry to be created by a user that has write permission on the 'entry' pseudo-attribute of the entry being created and also the 'children' pseudo-attribute of the parent entry.
From 2.4.13 onwards there is a per-database flag to enable full ACL
checking on added entries: add_content_acl yes
I would suggest always enabling that option. Here is an example that does not work as expected without it:
# 1: access to dn.exact="dc=people,dc=example,dc=org" attrs="children" by dn.exact="uid=admin,dc=people,dc=example,dc=org" write by * break # 2: access to dn.onelevel="dc=people,dc=example,dc=org" attrs="entry" by dn.exact="uid=admin,dc=people,dc=example,dc=org" write by * break # 3: access to dn.onelevel="dc=people,dc=example,dc=org" filter="(objectClass=inetOrgPerson)" by dn.exact="uid=admin,dc=people,dc=example,dc=org" write by * break
The only difference is that write access to attrs="entry" is granted separately before the rule that applies to real attributes. Without "add_content_acl yes" this masks the effect of rule 3 on add operations.
Summary:
Using ACLs for structure control is possible, but for all versions before 2.4.13 it is necessary to apply all the control via the "entry" pseudo-attribute.
From 2.4.13 onwards you should enable "add_content_acl yes".
I hope this will become the default in a future version.
Andrew