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

Re: Subordinate ACL question



Luke Howard wrote:

My understanding is that you want to confine in one rule all is required
to allow entry addition. This can be done at the cost of giving away more



Yes, my ACL configuration file is becoming too complicated (cue really bad joke about ACLs breeding).



rights than strictly required.  You need a <what> clause <dn> pattern that
matches both the parent and the newborn entry; in this case you can
simultaneously give access to "children", "entry" and "<attrlist>", at the
cost of giving the same access rights to the children of the newborn
entry, and to the parent's "entry" and "attrlist" attributes.  In your
case, I guess the only option is to use (going back to your very initial
example):

access to dn.regex="^(([^,]+),)?cn=([^,]+),CN=FOO$"
attrs=entry,children,@pilotPerson
  by dn.exact,expand="cn=$3,CN=FOO" write

This matches exactly "^cn=([^,]+),CN=FOO$" or a direct child of it. Hope
it helps.



Thanks, I'd prefer clear ACLs that are not overly permissive :-)

Note that in the first example, which is what I'm most keen to simplify,
the subject is not related to the object (the subject is a well known DN).
So there is no regex substitution needed.

All I want to do is allow this well known subject to create entries of a
particular class underneath another well known DN (and to be able to
create further entries subordinate to these newly created entries of the
same object class).

If I follow your logic, then will the following rule work (at the expense
of giving CN=BAR members access to the pilotPerson attributes of CN=FOO,
which I can live with)?

access to dn.subtree="CN=FOO" attrs=children,entry,@pilotPerson
by group/group/member.exact=CN=BAR


This is fine (at a first glance)

Or, the following, tighter rule:

	access to dn.onelevel="CN=FOO" attrs=children
		by group/group/member.exact=CN=BAR write

access to dn.children="CN=FOO" attrs=entry,@pilotPerson
by group/group/member.exact=CN=BAR write


This is not equivalent to the above, because while the members of "CN=BAR" will get access to the "entry" and "@pilotPerson" (pseudo-)attributes of all the entries below "CN=FOO" (second rule), they will get access to the "children" pseudo-attribute only of the direct (onelevel) children of "CN=FOO" (first rule). You should use "dn.subtree" instead, since you need that rule to apply to "CN=FOO" as well; as a result:

	access to dn.subtree="CN=FOO" attrs=children
		by group/group/member.exact=CN=BAR write

	access to dn.children="CN=FOO" attrs=entry,@pilotPerson
		by group/group/member.exact=CN=BAR write

is exactly what you need, i.e. access to "CN=FOO" is limited to adding immediate children, while access to its children allows to further "breed" them as well, i.e. create "nephews" and so.

My real concern is just having to repeat the same subjects for similar
ACLs. It would be nice to be able to group a bunch of subjects together
and just refer to them in subsequent rules.


You could look into dynamic groups, e.g. sets, or using memberURL to dynamically build group membership or so; for instance, a list of subjects, all with the same permissions, like:

	access to dn.subtree="CN=FOO" attrs=children
		by group/group/member.exact=CN=BAR write
		by dn.exact="CN=EXACT" write
		by dn.onelevel="CN=ONELEVEL" write


could be replaced by

	access to dn.subtree="CN=FOO" attrs=children
		by set="([CN=EXACT] | [CN=BAR]/member* | [ldap:///CN=ONELEVEL??one]/entryDN) & user" write

or by adding "CN=EXACT" to the "CN=BAR" group, and by adding "memberURL: ldap:///CN=ONELEVEL??one"; to the group entry "CN=BAR" and using your original ACLs.

I'd favour the latter solution, because sets are known to be inefficient, but, as you can see, they're very flexible (the URL option for sets is not in RE22 yet, sorry).

Ciao, p.



   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497