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
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
