[Freeipa-devel] Fwd: [PATCH] 912 Display the value of memberOf ACIs in permission plugin.

[Rob Crittenden]

Endi Sukma Dewata wrote:
> On 1/4/2012 12:20 PM, Rob Crittenden wrote:
>>> Also another thing, in _make_aci() in aci.py there are 2 exclusivity
>>> rules:
>>> * type, filter, subtree and targetgroup are mutually exclusive
>>> * filter and memberof are mutually exclusive
>>>
>>> Based on these rules it's possible to have memberof and targetgroup in
>>> the same permission, but not filter with targetgroup, which seems to be
>>> inconsistent because memberof generates a subset of ACI's generated by
>>> filter.
>>>
>>> The filter generates an ACI with a generic 'targetfilter=<filter>', and
>>> memberof seems to be a convenience method to generate an ACI with a more
>>> specific 'targetfilter=(memberOf=<memberof>)'.
>>>
>>> So the 2 rules should be combined because, like filter, memberof should
>>> be mutually exclusive from the other targets too.
>>
>> This is specifically allowed because it lets you restrict the members of
>> the memberof group to modify only the values of the targetgroup (e.g.
>> group membership). If anything I'd relax it so filter and targetgroup
>> aren't mutually exclusive. I'm not sure of the use case for this though.
>
> Hmm.. I think the memberof is used to define ACI target instead of the
> subject (bind rule). See the following command:

You're right. IIRC I added memberof to make v1-style delegation easier.

>
> ipa permission-add test --permissions=all
> --memberof=editors --targetgroup=ipausers
>
> It generates the following ACI:
>
> (targetfilter = "(memberOf=cn=editors,cn=groups,cn=accounts,
> dc=example,dc=com)")
> (target = "ldap:///cn=ipausers,cn=groups,cn=accounts,
> dc=example,dc=com")
> (version 3.0;acl "permission:test";allow (all)
> groupdn = "ldap:///cn=test,cn=permissions,cn=pbac,
> dc=example,dc=com";)
>
> If I understand correctly this ACI gives members of cn=test full access
> to members of cn=editors under the cn=ipausers subtree.

In this case there is no subtree, cn=ipausers is a group.

> To give members of cn=editors full access to cn=ipausers subtree I think
> the cn=editors would have to be added as a member of cn=test permission
> indirectly via privileges and roles.
>
> Since target and targetfilter attributes can co-exist in the ACI, I
> agree that we might want to relax the rules. So the permission target
> can be defined with a subtree, or a filter, or both. With a subtree we
> can specify either a generic subtree, a type, or a targetgroup. With a
> filter we can specify either a generic filter or a memberof. Is this
> correct?
>
> This will require some UI changes too.
>

There are a lot of things we CAN allow, the 389-ds acis are extremely 
flexible. The question is do we need to? I'm all for providing lots of 
rope but acis are very hard to get right and can be difficult to read 
and debug which is why I tried to keep things as simple as I could. I 
think its fine if we have some constraints.

rob