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

[Rob Crittenden]

Endi Sukma Dewata wrote:
> On 1/4/2012 2:32 PM, Rob Crittenden wrote:
>>> 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.
>
> Right, specifying filter/memberof with targetgroup doesn't make sense
> because there's no entries under the group. But it's still possible to
> create useful ACI by specifying filter/memberof with type/subtree. For
> example, the following permission targets users that are members of
> editors only:
>
> ipa permission-add test --permissions=all
> --memberof=editors --type=user
>
> It will generate the following ACI target:
>
> (target = "ldap:///uid=*,cn=users,cn=accounts,dc=example,dc=com")
>
>>> 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?
>>
>> 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.
>
> Either one is OK for me.
>
> For consistency & simplicity it might be better to combine the rules
> such that filter, memberof, type, subtree, and targetgroup are mutually
> exclusive. The memberof wasn't available in the UI before and the CLI
> support wasn't complete either, so I'm not sure if anybody is relying on
> this feature prior to this.
>
> But if we want more flexibility to support scenario like above with
> filter/memberof and type/subtree together, we will need to split the
> target into subtree and filter as described earlier.
>

I guess I'm just not convinced this additional complexity would buy us 
anything.

Updated patch attached that fixes the memberof display and updates the 
tests trivially.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-rcrit-912-1-permission.patch
Type: text/x-patch
Size: 7290 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120104/085d6d4d/attachment.bin>