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

[Martin Kosek]

On 04/10/2014 03:10 PM, Petr Viktorin wrote:
> On 04/10/2014 03:07 PM, Martin Kosek wrote:
>> 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.
> 
> Right, that makes sense. I'm asking about not having separate read privileges
> when the permissions are group based. Based on Simo's other mail we should have
> separate "Read" privileges.
> 
> Also IMO the read permissions should then be added both to the "Reader" and
> "Administrator" privileges, since it doesn't make sense to be able to write but
> not read.

Ah, I understand the question now. This assumes that people may often want to
allow a certain group of people to read RBAC or to read ticket policy.

I would assume that a more frequent usage would be that administrator would
allow all authenticated users read an object (which makes Read group
redundant). But I am not insisting, I am open to both approaches.

Martin