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

[Jason Rist]

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?
>
>
> 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?

-J

-- 
Jason E. Rist
Senior Software Engineer
Systems Management and Cloud Enablement
Red Hat, Inc.
+1.919.754.4048
Freenode: jrist