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

[Endi Sukma Dewata]

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.

-- 
Endi S. Dewata