[Beaker-devel] Clarification request for Enhanced User Groups

Nick Coghlan ncoghlan at redhat.com
Tue Apr 30 07:25:37 UTC 2013


On 04/30/2013 05:01 PM, Jan Stancek wrote:
>
>
>
>
> ----- Original Message -----
>> From: "Nick Coghlan" <ncoghlan at redhat.com>
>> To: "Dan Callaghan" <dcallagh at redhat.com>
>> Cc: "beaker-devel" <beaker-devel at lists.fedorahosted.org>
>> Sent: Tuesday, 30 April, 2013 7:53:38 AM
>> Subject: Re: [Beaker-devel] Clarification request for Enhanced User Groups
>>
>> On 04/30/2013 01:14 PM, Dan Callaghan wrote:
>>> Excerpts from Nick Coghlan's message of 2013-04-30 11:51:32 +1000:
>>>>> Also, how does the existing group/job permission model fit into
>>>>> this?
>>>>> i.e if you're in the same group as the submitter you can ack/nak.
>>>>
>>>> I'm open to alternative suggestions, but my initial reaction is that,
>>>> for individually owned jobs, the permissions granted to group members in
>>>> the current model should be granted to "group members with job
>>>> modification permissions" in the revised model.
>>>
>>> On the contrary, I think all that stuff should just go away entirely for
>>> "individually owned jobs" (which I assume to mean, a job submitted *not*
>>> on behalf of a group, that is <job group=""/>). For individually owned
>>> jobs, only the owner can modify them.
>>
>> OK, that makes sense.
>>
>> Getting back to the original Q in the thread, Dan and I think we've come
>> up with a superior model that both simplifies the group model *and*
>> simplifies the "automated account submitting jobs on behalf of users"
>> use case.
>>
>> Specifically, here's what I'm thinking:
>>
>> 1. The "job modification" privilege goes away. All group members can
>> modify jobs submitted on behalf of that group.
>> 2. Each user account gains the ability to specify other accounts that
>> can submit jobs on their behalf
>> 3. When submitting a job, you can nominate a different user that will
>> appear as the job submitter. All other permissions (including future
>> modifications to the job, and whether or not you can submit the job on
>> behalf of a group) will be based on that user, rather than the automated
>> account.
>>
>> This may be clearer with an example:
>>
>> We have a user "Bob", who is a member of the group "Bob's Team"
>> Bob has an automated account "SubmitBot" that he wants to use to submit jobs
>> On his user profile page, Bob adds "SubmitBot" to a list of user's that
>> are authorised to submit jobs on Bob's behalf.
>
> Could this also be a group option? I'd like to avoid running from one maintainer
> to other asking them to update their settings. Something like:
> - Admin of Bob's team adds "SubmitBot" to list of users that are authorised to submit
> jobs on behalf of members in Bob's team.

Enabling that approach is actually where my original "Job Modification" 
design came from. It just turned out to have other issues that made it a 
bad idea :)

However, I think we can do something slightly different in the revised 
design that will still handle that case:

1. If SubmitBot is submitting an individual job with the nominal 
submitter as "Bob", then SubmitBot must be in Bob's delegation list
2. If SubmitBot is submitting a group job for "Bob's Team" with the 
nominal submitter as "Bob", then SubmitBot must be in Bob's delegation 
list OR in the delegation list for "Bob's Team"

The reason for the extra restriction is that users can be in multiple 
groups, so the group based delegations shouldn't bleed across in those 
cases.

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