[katello-devel] System Group permission recap

[Justin Sherrill]

On 05/04/2012 11:38 AM, Todd Warner wrote:
> On 05/03/2012 04:03 PM, Justin Sherrill wrote:
>> Was thinking about this a bit more, and after our discussion i did
>> want to emphasize something:
>>
>> In katello the create verb on every type of object (which we call
>> manage in the UI), gives you Create/Read/Update on every instance of
>> that object type.  This continues with System Groups.
>>
>> For example:  If bob has the ability to create groups, he can also
>> Read and Update (including system membership) ANY Group in that
>> organization.  For the case that taw brought up, where you have a read
>> only auditor that is allowed to create groups and run some sort of
>> report on the group, this would give them the ability to modify the
>> system membership in any group.
>>
>>   Now if this auditor didn't really need the ability to create  (if
>> someone else creates it for him), then there really isn't an issue.
>> I'm not extremely familiar with this use case so you could elaborate
>> taw on if this is a problem or not?
> Good question, and I wish I could say I have a slam-dunk answer. My
> first inclination is that each element of CRUD has it's own permissions.
> The C&R can be combined... and maybe even D. But update... hmm...
>
> I think for the interim, if they can create they acquire the other
> attributes as well. That being said, I don't like having system
> inheriting permissions to begin with, and if they couldn't, it wouldn't
> be a problem. I.e., Ability to delete systems from a group shouldn't
> mean you can delete systems.
>
> This doesn't help at all does it?

The problem with not automatically giving U with create is it then 
requires someone with role management access to then give that user 
specific update capabilities to that entity after the user created it.  
We don't have a way to automatically let users edit something they 
create (and don't have a simple answer to that).  In most cases that's 
ok, but with this auditor use case it causes issues.

As for the delete systems, it doesn't propagate in that way.  The 
ability to remove systems from a group (which i think is what you 
meant), does NOT give you the ability to delete a system.  There is a 
permission "Delete systems in group X"  that would allow you to do that, 
but it is completely separate from the 'modify system membership of 
Group X' permission.

So i guess the answer is, that's ok for now?

-Justin


> -todd
>
>>
>> Thanks,
>>
>> -Justin
>>
>>
>>
>> On 05/03/2012 01:48 PM, Justin Sherrill wrote:
>>> Hi All,
>>>
>>> So after an intense discussion about System Groups and their
>>> permissions, we've come up with the following permission model for
>>> system groups:
>>>
>>>      Verbs:
>>>        Create/Manage
>>>        Read group  X
>>>        Modify details and system membership of group X
>>>        Lock/Unlock group X
>>>        Delete Group X
>>>        Modify systems in group X (affects what is listed on the
>>> systems page)
>>>        Read systems in group X (affects what is listed on the systems
>>> page)
>>>        Delete systems in group X
>>>
>>> With the following notes:
>>>   - System visibility is additive and is determined by a union of the
>>> following permissions:
>>>     *  Read Systems  in Org A
>>>     *  Read Systems in Env B
>>>     *  Read Systems in Group C
>>>   - So if a user has the above 3 permissions, a system would be
>>> readable if it were in Org A or Env B or Group C.
>>>   - Same goes with "modify systems" on groups, orgs, environments
>>>   - A user can add a system Y to a group Z assuming the following 2
>>> conditions:
>>>     * The user has the permission 'modify group Z'
>>>     * The user has at least the ability to read system Y as determined
>>> by one of the 3 rules above
>>>   - The above means that a user can elevate the permissions he has on
>>> a system from read-only to read/write if
>>>     * He has modify permission for some group X
>>>     * He has "modify systems in group X" permission
>>>     * He currently has read-only access to the system
>>>     * This needs to be made very clear in the UI that "modify group"&
>>> "modify systems in group" permission could provide privilege
>>> escalation for a system.
>>>
>>> Let me know if you have any questions.
>>>
>>> -Justin
>>>
>>> _______________________________________________
>>> katello-devel mailing list
>>> katello-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/katello-devel
>