[Freeipa-devel] [PATCHES] 0464-0466 Multivalued targetfilter

[Martin Kosek]

On 02/13/2014 01:12 PM, Petr Viktorin wrote:
> Hello,
> These patches fix https://fedorahosted.org/freeipa/ticket/4074
> Design: http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions
> 
> 
> Since --type, affects only targetfilter values in the form "(objectclass=...)"
> and leaves others alone, and in the -mod command we don't fetch the existing
> entry until the pre_callback, I had to put the adds/removes in the context. I
> don't think the approach is too terrible given the limitations.

464:

1) Internal Error:

# ipa permission-mod can_write2 --filter='foo=bar'
ipa: ERROR: an internal error has occurred

2) ACI target filter

I would relabel targetfilter from "ACI target filter" to "Target filter" to
make it consistent with other ACI attributes. We are sort of hiding there are
any underlying ACIs anyway...

3) I am now thinking about the behavior of --memberof and --filter options and
how they interact. It looks OK except for the case when I set filter to None:

# ipa permission-mod can_write2 --memberof=bar
--------------------------------
Modified permission "can_write2"
--------------------------------
  Permission name: can_write2
  Permissions: write
  Effective attributes: description
  Bind rule type: permission
  Subtree: dc=example,dc=com
  ACI target filter: (foo=bar),
                     (memberOf=cn=bar,cn=groups,cn=accounts,dc=example,dc=com)
  Member of group: bar
# ipa permission-mod can_write2 --filter=
--------------------------------
Modified permission "can_write2"
--------------------------------
  Permission name: can_write2
  Permissions: write
  Effective attributes: description
  Bind rule type: permission
  Subtree: dc=example,dc=com

Then both memberOf and filter is erased. Are we ok with that? Shouldn't we keep
memberOf part until that is set to None? I am not insisting, just trying to
discuss the best behavior.

465: I know this was already discussed previously, but I am now having second
thoughts - should we use posixAccount as THE objectclass for user targetfilter?

# ipa permission-add can_write --permissions write --attrs=description --type=user
----------------------------
Added permission "can_write"
----------------------------
  Permission name: can_write
  Permissions: write
  Effective attributes: description
  Bind rule type: permission
  Subtree: cn=users,cn=accounts,dc=example,dc=com
  ACI target filter: (objectclass=posixaccount)
  Type: user

What if we add system users at some point which would miss the posixaccount
objectclass? Wouldn't it be better to use the inetOrgPerson structural
objectclass instead of posixAccount? Simo or Ludwig, any opinion on this?

Otherwise the patches worked fine for me.

Martin