Emmanuel Dreyfus wrote:
Hello
sets ACL are definitvely hard to work with. But perhaps my schema is just plain wrong. Any hint (how to build the ACL or how to redesign the schema) is welcome. Here is the problem:
A) The schema I have three clases:, ou, person, mailAddress
- persons are children of ou. They have three interesting attribute: ou: the ou they belong to mail: the mail addresses they receive mail from (multivalued) uid: the person's acount login
A person's DN is like uid=jdoe,ou=sales,dc=example,dc=net
- mailAddress holds a bunch of parameters about a mail address. It has
a mail attribute. A mailAddress DN is like mail=John.Doe@example.net,dc=example,dc=net
mailAddress are not children of ou, since several persons of different ou may receive mail through the same address.
This is an interesting setup. Usually I would make such associations explicit using an "owner" attribute or somesuch. It feels like what's wanted here is a "dynamic member" type of attribute, the opposite of a dynamic group. The main point being there should be an explicit DN-valued attribute associating an email address entry to all of its user entries. Probably the refint overlay could be enhanced to maintain this type of relation. As things currently are, you'd have to use some external procedures to keep such an attribute up to date.
- ou have two interesting attrbiutes: ou: the unit name manager: DN of persons acting as managers (multivalued)
An ou DN is like ou=sales,dc=example,dc=net
B) The goals
- a person must be able to modify a mailAddress when it receives mail
from this address. This is done by an ACL clause like this (obtained from this mailing list) by set.exact="this/mail & user/mail" write It works very well. That goal is fullfilled.
If each address entry had an owner attribute, it would just be: by dnattr=owner write
- a user listed as a manager for an ou must be able to modify the
persons within the ou. I've came to the following:
Ando already responded to this. But here I would use the collective attributes overlay, to propagate the manager attribute to all children of the ou. Then the ACL is again very simple: by dnattr=manager write
- The trickiest part, for which I have no solution: a user listed as a
manager for an ou must be able to modify the mailAddress that a user he can modify could modify.
With the above considerations in place, this would just be by set.exact="this/owner/manager & user" write