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

[Justin Sherrill]

On 05/16/2012 02:18 PM, Bryan Kearney wrote:
> On 05/16/2012 09:59 AM, Jason Rist wrote:
>> On 05/15/2012 11:51 AM, 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?
>
> Really? Why? Seems like we are missing KISS some place.

This was part of the original requirements document that was discussed 
pretty heavily.   I'll let Taw weigh in on the need for it.

>
>
>>>
>>>
>>> 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
>>
>> I like B too, actually. Seems to make the most sense to me as well.
>> Plus, I could see us using Locking in other places, like for Roles?
>
> I dunno.. I wonder if more fine gained is a pain in the butt, but 
> allows differnet use cases we have not thought of.
>
> -- bk
>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel