Howard Chu wrote:
The above was wrong anyway. It should have been: access to dn.subtree="ou=classlists,o=linfield.edu" attrs=uniquemember,owner by dnattr=owner write access to dn.subtree="ou=classlists,o=linfield.edu" by dnattr=owner write by * read(Remember, most specific first, unless you muck up the order with breaks.)A DN that is an owner at the top level, "ou=classlists,o=linfield.edu" should have full read/write access to that object and to everything underneath. Someone who is an owner in a particular subject node, e.q., "ou=mat,ou=classlists,o=linfield.edu", should have full read/write access to that node and everything underneath, but not to anything else.See the FAQ-o-Matic. http://www.openldap.org/faq/index.cgi?file=653
The above setup let me successfully fully view and write to any entry where my DN (that I'm binding with) is amongst the values of the owner attribute for that entry. What's missing is that if my DN is amongst the values for the owner attribute of the parent or the grandparent, I need to have full privileges. To that end, and after having spent some time reading through the FAQ, I came up with the modified set below. Right now, in theory, as long as my DN is in the owner attribute at the top of the ou=classlists hierarchy, I should have access to every entry in the hierarchy. The bottom line is that the access granted after adding the "by group" is no different.
The ACLs now look like this: access to dn.subtree="ou=classlists,o=linfield.edu" attrs=uniquemember,ownerby group/groupOfUniqueNames/owner.exact="ou=classlists,o=linfield.edu" write
by dnattr=owner write access to dn.subtree="ou=classlists,o=linfield.edu" by dnattr=owner write by * read So I'm still missing something that I don't understand. -- Rob
smime.p7s
Description: S/MIME Cryptographic Signature
