[katello-devel] (Another) System Group permissions question
Lukas Zapletal
lzap at redhat.com
Wed May 16 08:24:48 UTC 2012
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?
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
--
Later,
Lukas "lzap" Zapletal
#katello #systemengine
More information about the katello-devel
mailing list