[Freeipa-devel] [PATCH] 0513 Add managed read permissions to permission

[Martin Kosek]

On 04/10/2014 03:02 PM, Petr Viktorin wrote:
> On 04/10/2014 02:58 PM, Martin Kosek wrote:
>> On 04/10/2014 01:46 PM, Petr Viktorin wrote:
>>> On 04/09/2014 05:17 PM, Martin Kosek wrote:
>>>> On 04/09/2014 04:54 PM, Petr Viktorin wrote:
>>>>> The meta-permissions.
>>>>
>>>> :-)
>>>>
>>>>> Read access is given to all authenticated users. Reading membership info
>>>>> (i.e.
>>>>> privileges) is split into a separate permission.
>>>>>
>>>>> Another permission is added that allows read access to all ACIs.
>>>>> If we don't want to open that up for everyone, I could limit this to only
>>>>> ACIs
>>>>> containing "permission:". (Since old-style permissions store their
>>>>> information
>>>>> in ACIs, their ACIs need to be readable.)
>>>>
>>>> If I read the notes from our DevConf discussion correctly, there are some
>>>> inconsistencies:
>>>>
>>>> 1) We decided to not do special membership permission for
>>>> permission/privilege/role permissions.
>>>>
>>>> 2) We decided to give read access to permissions, privileges and roles only to
>>>> member of a certain privilege. Is there any reason to not do that? IMO,
>>>> regular
>>>> users do not need to be able to read the permission/privilege/role
>>>> configuration of a FreeIPA installation to use it for IdM.
>>>>
>>>> Martin
>>>>
>>>
>>> Updated. I plan to add all the RBAC-related read permissions to a single
>>> privilege, "RBAC Readers". Or do we want more granularity by default?
>>>
>>> Requires my patch 0514.
>>
>> I was looking at the granularity we currently have with privilege and it is
>> mostly per FreeIPA function (Sudo Administrator or DNS Administrator), not per
>> IPA object (Sudo Command Administrator, Sudo Rule Administrator).
>>
>> I would thus follow the same principle with RBAC and create RBAC Administrator
>> privilege which will cover read permissions for... permissions... privileges
>> and roles. In time, we will also add new write privileges there as they are
>> currently missing.
>>
>> To sum it up, the patch works, I would just change the name of the privilege
>> and not focus it just on reading.
> 
> So to confirm, we want one privilege to cover both reading and writing?

IMO, yes.

> Should I add new read permissions to existing "Administrator" privileges only,
> instead of creating new "Reader" permissions?

I don't think so. The read permission we have been adding so far were targetted
on anonymous/all binds, thus according to our design, they cannot be added to
privilege anyway.

But if someone wants to restrict an object, he is free to change the permission
bind type to "group based" and assign it to a privilege.

In our case, I would assign read permission to privilege only if we decided to
make them group based, like RBAC or krbtpolicy ones.

Martin