[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Need some help with ACLs

On 09/20/2006 01:57 PM, Quanah Gibson-Mount wrote:

access to dn.subtree="ou=classlists,o=linfield.edu"
by dnattr=owner write
access to dn.subtree="ou=classlists,o=linfield.edu" attrs=uniquemember,owner
by * none
access to dn.subtree="ou=classlists,o=linfield.edu"
by * read

This gets me half way to my goal. With the first ACL in place and logging in as an owner (my DN in the owner attribute), I can see all the nodes immediately beneath "ou=classlists,o=linfield.edu", but I cannot see objects beneath them.

Here's what I need: anybody with access to the ldap server, authenticated or anonymous, should be able to see anything in the ou=classlist hierarchy except the uniquemember and owner attributes (for those of you in higher education, it's for FERPA compliance). However, owners should be able to see and modify there own entries.

The hierarchy is set up like this: the top is: "ou=classlists,o=linfield.edu". The next layer down is "ou=<subject>,ou=classlists,o=linfield.edu". There are currently 47 such nodes, one for each subject area in the catalog. Underneath that are the objects, one for each course section offered in any given academic term. They define course mailing lists. There are thousands of those. At each level, there are owner attributes.

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. Faculty are the owners of their own course section objects, and should have full read/write access to each object that they own.

I come from a netscape background where ACIs (as opposed to ACLs) were stored in the hierarchy itself, and each subject node had those ACIs that applied to it and to those objects immediately below. I am having trouble translating them into OpenLDAP.



Rob Tanner
UNIX Services Manager
Linfield College, McMinnville OR

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature