[katello-devel] (Another) System Group permissions question

[Justin Sherrill]

On 05/16/2012 04:24 AM, Lukas Zapletal wrote:
> Variation C looks like the easiest path, but I am not sure if I
> understand system group vs environment association correctly. Do we have
> more doco about this?
https://www.redhat.com/archives/katello-devel/2012-May/msg00009.html

By going with C  you'd basically be saying that some user Fred with 
:update can only add systems within Environments A or B.  But if fred 
wants to he can just change the environments thus removing the 
restricution all together. Which gets to the real question: What's the 
goal of this environment locking?

i) To restrict what systems users can add to a system group

ii) A convenience factor in helping organize groups

If the goal is i), then C does not make sense.  If the goal is ii), then 
C should be fine.  All three solutions are fairly trivial to implement.

-Justin

> LZ
>
> On Tue, May 15, 2012 at 01:51:21PM -0400, Justin Sherrill wrote:
>>
>> As part of the system group work, we are adding the ability to
>> optionally associate environments with a system group to lock down
>> group membership to only systems in a set of environments.  So as
>> part of this, how do we restrict who can modify environments
>> associated with a system group?  And further, what is the end goal
>> to modifying environments?
>>
>>
>> We currently have the following verbs for system group permissions:
>>         :create =>  _("Administer System Groups"),
>>         :read =>  _("Read System Group"),
>>         :update =>  _("Modify System Group details and system membership"),
>>         :delete =>  _("Delete System Group"),
>>         :locking =>  _("Lock/Unlock System Group"),
>>         :read_systems =>  _("Read Systems in System Group"),
>>         :update_systems =>  _("Modify Systems in System Group"),
>>         :delete_systems =>  _("Delete Systems in System Group")
>>
>>
>> Initially you would think the :update would be the ideal candidate
>> to allow access to modifying environments.  However, if the goal is
>> to restrict what systems (by environment) another user can add to
>> the group then it wouldn't make sense to give that user access to
>> modify the environments that are restricted.
>>
>> Possibilities are:
>>
>> a)  add a new permission to modify environments
>> b)  turn 'locking' into a new administrative verb and group
>> environment association with that (some sort of Group Admin
>> permission).  To me this makes the most sense, as both associating
>> environments and locking/unlocking are dealing with the same sort of
>> action (whether a system can be added to a group).  So you would end
>> up with something like
>>
>>     :restrict_modification =>  ("Lock/Unlock a group and modify group
>> environment restrictions")
>>
>> c)  Throw the restriction out the window and allow anyone that can
>> modify membership (:update) to be able to modify the associated
>> environments.
>>
>>
>> Thoughts?
>>
>> -Justin
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel