[Freeipa-devel] [RFE] Permissions V2

[Petr Viktorin]

On 12/06/2013 03:54 PM, Rob Crittenden wrote:
> 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.

The design changes --type to be a "shortcut" for setting location and 
filter at the same time. Those two are what's actually stored in LDAP, 
and on output "type" is added if those two match a known object type.

We may (in the RFE I'm about to file) want to make targetfilter & 
targetattrfilter multivalued, and e.g. make --type work on objectclass 
filters only.

-- 
Petr³