[Beaker-devel] Clarification request for Enhanced User Groups

Nick Coghlan ncoghlan at redhat.com
Tue Apr 30 00:25:57 UTC 2013


<moving to the public dev list, no reason for this to be in private email>

On 04/29/2013 08:01 PM, Raymond Mancy wrote:
> Just a couple of questions regarding this following sentence:
>
>    All members of the group with job modification permissions will be able to ack/nack, change priority,
>    edit whiteboard, and change retention tag.
>
> 'All members of the group with job modification permissions', does this actually translate to 'All members
> of the job's group owner'. I'm assuming it is, I was just momentarily confused by it.

No, it's not enough to be a member of the owning group, your membership 
in that group also has to be flagged as "can modify jobs".

See the first part of the proposal (before the "Group ownership" section):

==========
All members of a group are able to submit jobs on behalf of that group.

Group members may also be granted the following additional permissions 
on a group:

     * group ownership
     * group job modification
==========

This means there are two independent permissions on groups, above and 
beyond the "can submit jobs on behalf of the group" capability:

1. Group ownership
   - can add/remove members
   - can change owner status of members
   - can change job modification permissions of members

2. Job modification
   - can modify jobs owned by the group after they are submitted

The intent of this separation is to allow an automated process to be 
given the ability to submit jobs on behalf of the group, *without* 
granting the automated tool's account the ability to modify those jobs 
after creation.

While technically a group owner may not necessarily have job 
modification permissions, they can grant themselves those permissions at 
any time, so it's not a real restriction (from the code's point of view, 
it means we can ignore the group ownership flag when checking for job 
modification permissions).

The default settings when adding a new member to a group are:
   - Group Owner?: False
   - Can Modify Jobs?: True

> Also, is there a reason why we can't afford the group owner the exact same permissions as the
> job submitter (specifically Delete, which is not mentioned)? This would probably make the docs a bit
> more maintainable (as in '...with job modification permissions equal to that of the job submitter' rather than
> having to update it every time a new job action is created). This would also make the code simpler.

It's meant to be full access - if I missed any current capabilities, 
it's just a mistake in the design.

However, note that part of the redesign is that the job submitter may 
*not* have permissions to make changes after submission, if they're 
submitting the job on behalf of a group and they don't have the job 
modification flag for that group.

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane

Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/)
PulpDist Development Lead (http://pulpdist.readthedocs.org)


More information about the Beaker-devel mailing list