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

Re: Another ACL question about set usage

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

1) 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


2) 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.

3) 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

1) 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

2) 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

3) 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

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  Chief Architect, OpenLDAP     http://www.openldap.org/project/