Re: Need some help with ACLs

[Rob Tanner <rtanner@linfield.edu>]

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.

Thanks,
Rob


--

Rob Tanner
UNIX Services Manager
Linfield College, McMinnville OR

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