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.
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.
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:
access to dn.regex="uid=.+,ou=(.+),dc=example,dc=net$" by set.expand="[ou=$1,dc=example,dc=net]/manager* & user" write
That works, though it seems to be very poor on the performance front. I tried something more simplier, such as: by set.exact="this/ou/manager & user" or that way: by set.exact="(this/ou+[,dc=example,dc=net])/manager & user" but it does not work, I have no idea why. I'm very curious to learn what's wrong here.
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.
I can try to rephrase this a bit better. If I have the following (mailAddress, person, ou) triplet dn: mail=W,dc=example,dc=net
dn: uid=X,ou=Y,dc=example.dc=net mail: W
dn: ou=Y,dc=example,dc=net manager: Z
I want user Z to be able to modify mailAddress W
Here is an attempt that does not work by set.exact=" ([uid=*,ou=] + ([manager=] + user)/ou*) + [,dc=example,dc=net])/mail & this/mail" write
I also attempted various tricks with ldap:/// lookups, but no luck.
Emmanuel Dreyfus wrote:
- 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.
Looks just fine.
- 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:
access to dn.regex="uid=.+,ou=(.+),dc=example,dc=net$" by set.expand="[ou=$1,dc=example,dc=net]/manager* & user" write
That works, though it seems to be very poor on the performance front.
Not sure you need to further expand the manager (the "star" at the end of /manager*). Furthermore, if that's your real DN layout, you could try something like
access to dn.regex="^uid=.+,(ou=.+,dc=example,dc=net)$" by set.expand="[$1]/manager & user" write
I also note that
access to dn.regex="^uid=.+,(ou=.+,dc=example,dc=net)$" by group/organizationalUnit/manager.expand="$1" write
should be equivalent and much more efficient (but, AFAIK, organizationalUnit does not allow manager!).
The above says that if you treat the objectClass "organizationalUnit" as a group, and "manager" as the group's member attribute, and the manager's value matches the user's identity, access is granted.
I tried something more simplier, such as: by set.exact="this/ou/manager & user" or that way: by set.exact="(this/ou+[,dc=example,dc=net])/manager & user" but it does not work, I have no idea why. I'm very curious to learn what's wrong here.
As far as I understand, "ou" contains the name of the organizationalUnit, not its DN. So set expansion does not work, because it only acts on DNs. Maybe something like
by set.exact="([cn=]+this/ou+[dc=example,dc=net])/manager & user"
You see, in the last case you were almost there: all you're missing is the [cn=]+ at the beginning of the DN. But see my much cleaner example above, which should be the most efficient thing you can do.
- 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.
I can try to rephrase this a bit better. If I have the following (mailAddress, person, ou) triplet dn: mail=W,dc=example,dc=net
dn: uid=X,ou=Y,dc=example.dc=net mail: W
dn: ou=Y,dc=example,dc=net manager: Z
I want user Z to be able to modify mailAddress W
Here is an attempt that does not work by set.exact=" ([uid=*,ou=] + ([manager=] + user)/ou*) + [,dc=example,dc=net])/mail & this/mail" write
This seems to be hard to get. As far as I understand:
- your final relation should be ANS ::= "this/mail & USERS/mail"
- where USERS is defined as USERS ::= "[ldap:///OUDN??one]/entryDN"
- but what's missing is how to compute OUDN from what you've got; this should do what you need: OUDN ::= "([ldap:///dc=example,dc=net??one(manager=]+user+[)])/entryDN"
so performing the substitutions, and breaking up and combining literals as appropriate
by set.exact="this/mail & ([ldap:///]+([ldap:///dc=example,dc=net??one(manager=]+user+[)])/entryDN+[??one]/entryDN)/mail"
the above should work. Unless I missed something in your description, of course.
Note that performances will be ugly...
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
Pierangelo Masarati wrote:
so performing the substitutions, and breaking up and combining literals as appropriate
by set.exact="this/mail &([ldap:///]+([ldap:///dc=example,dc=net??one(manager=]+user+[)])/entryDN+[??one]/entryDN)/mail"
the above should work. Unless I missed something in your description, of course.
As I said in my previous posting, literals must be combined in the appropriate manner; the above, however, is not. The right string is
by set.exact="this/mail & ([ldap:///]+(([ldap:///dc=example,dc=net??one?(manager=]+user+[)])/entryDN+[??one])/entryDN)/mail"
Tested right now with HEAD, seems to work as expected.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
by set.exact="this/frESPCImail & ([ldap:///]+(([ldap:///dc=espci,dc=fr??one? (frESPCImanager=]+user+[)])/entryDN+[??one])/entryDN)/rfc822mailbox"
I'm trying to understand that set. There is a first step: ldap:///dc=espci,dc=fr??one?(frESPCImanager=]+user+[)])/entryDN
That retreive the ou's DN for which the user is a manager. Why can't we write it that way? ([frESPCImanager=]+user)
Let's call OU_MANAGER the result of the above query. We are left with that second step:
[ldap:///]+OU_MANAGER+[??one])/entryDN)/rfc822mailbox"
We so perform a query for all users' rfc822mailbox within OU_MANAGER. Again, why the following would be wrong? ([ou=]+OU_MANAGER+[,dc=espci,dc=fr])/rfc822mailbox
Let's call MANAGED_MAILADDR the result of the above operation, the last operation is this/frESPCImail & MANAGED_MAILADDR
That one is obvious to understand, no problem.
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
Emmanuel Dreyfus wrote:
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.
I should definitely revitalize and fix my memberof overlay...
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
openldap-software@openldap.org
-
Howard Chu -
manu＠netbsd.org -
Pierangelo Masarati