[Freeipa-devel] [RFE] Permissions V2

[Rob Crittenden]

Simo Sorce wrote:
> On Fri, 2013-12-06 at 15:46 +0100, Petr Viktorin wrote:
>> On 12/06/2013 03:28 PM, Simo Sorce wrote:
>>> On Fri, 2013-12-06 at 14:14 +0100, Petr Viktorin wrote:
>>>> On 12/02/2013 02:48 PM, Petr Viktorin wrote:
>>>>> On 12/02/2013 02:29 PM, Simo Sorce wrote:
>>>
>>>>>> It would be very nice if you can add the resulting LDAP objects in the
>>>>>> example, that will allow me to reason on the correctness of the
>>>>>> translation.
>>>>>
>>>>> OK, I'll work on that.
>>>>
>>>> I've added the resulting LDAP objects to the tests here:
>>>> http://www.freeipa.org/index.php?title=V3/Permissions_V2/tests
>>>
>>> Thank you Petr,
>>> I was looking at them and I see we often use target=ldap://<dn> type for
>>> selecting which objects this apply to.
>>>
>>> This was sort of necessary when the permissions were all in the base and
>>> we wanted to limit to specific entries in subtrees.
>>>
>>> However I was wondering if we shouldn't transition/allow to user
>>> targetfilter or targetattrfilter (this would be needed to have
>>> add/delete permissions).
>>>
>>> For example, instead of:
>>>     (target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX")
>>> We could have:
>>>     (targetfilter = "(objectclass=ipaUser)")
>>>
>>> It also occurs to me we could do very neat things like allowing manager
>>> access with (targetfilter = "(managedby=<dn>)"), and similar.
>>>
>>> In general using targetfilter and targetattrfilter is more flexible and
>>> allow for applying different permission depending exacly on the object
>>> type or even specific sets of objects of a common type. Something the
>>> simple target filter cannot do.
>>>
>>> What do you think ?
>>
>> +1
>>
>> I don't think this should block the framework patches that are on list
>> now, though. I'll file a RFE for tuning how the default and "type"
>> permissions look. Would that be fine?
>
> Do we need a new attribute, or do you think we can do this without
> changing the schema ?

Right now type implies the target used. I think it would just change to 
be a targetfilter instead (or a piece of one anyway). What may be tricky 
is combining a type and a user-profiled filter, and then decomposing 
that, without a separate attribute.

rob