On Fri, Dec 05, 2008 at 12:37:36PM +0000, Andrew Findlay wrote:
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 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.
I should also point out that while the rules above do force every new entry to have objectClass=inetOrgPerson they do not prevent other auxiliary objectclasses from being added to the entry. Thus if your structure rules are there to enforce security you may still have a problem. You may be able to mitigate the problem by denying write access to attrs="entry" if certain sensitive attributes exist in the entry, but it is clumsy.
From 2.4.13 onwards there is a per-database flag to enable full ACL checking on added entries: add_content_acl yes
That is the proper fix for the problem, as it allows you to grant write access to just those attributes you want to appear in the entry.
Andrew