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.


Freeipa-devel mailing list

Reply via email to