[Beaker-devel] Some thoughts on system access policies

Nick Coghlan ncoghlan at redhat.com
Wed Jul 31 04:04:19 UTC 2013


On 07/31/2013 01:35 PM, Dan Callaghan wrote:
> I don't think it's necessary that a policy have any kind of owner. The 
> ability to modify the policy would be controlled by a permission on the 
> policy itself (``edit-policy`` below). The system owner controls what 
> policy applies to their system.
> 
> (I also think Beaker's current requirement that every system have 
> exactly one owner is not adequate, but I don't think we should try and 
> tackle that right now.)
> 
> What if "predefined access policies" were first class named entities, 
> not tied to anything else? The custom access policies for each system 
> which be represented in the same table, but as anonymous, hidden 
> policies referencing a single system. So the UI at the system level 
> would be: pick a predefined policy from the list, create a new named 
> policy, or make a custom one for this system. Then users can set up 
> predefined policies associated with whatever they want ("Company-wide 
> shared systems", "Kernel QE hardware", "dcallagh's systems").
> 
> So this is essentially back to the system pools idea, except only for 
> access control purposes, not trying to conflate all the other different 
> purposes.

Yeah, with the change of name and the clear separation of purpose (i.e.
access policies have nothing to do with scheduling beyond "yes you can
use it"), I like it.

>> In terms of permissions, the list in the current system pools proposal
>> looks pretty good:
>>
>>     edit system details (edit-system)
>>     loan system to anyone (loan-any)
>>     loan system to self (loan-self)
>>     issue power and provisioning commands (control-system)
>>     implicitly schedule recipes on the system when submitting jobs
>> (schedule-recipe)
>>     reserve system manually (via web UI or bkr client) (reserve-manual)
> 
> The last two are really equivalent, it just depends whether the system 
> is set to run scheduled jobs (Automated) or must be manually reserved 
> (Manual). I had merged them into one permission ``reserve`` in my patch.

Makes sense.

>> However, we may want to consider some additions:
>>
>>     edit access policy (edit-policy)
>>     switch access policy (switch-policy)
>>     explicitly request the system when submitting jobs (schedule-explicit)
>>
>> edit-policy refers to changing the policy itself. If we don't add it,
>> updates would be limited to the owning user (for user access policies)
>> or owners of the owning group (for group access policies)
> 
> As above, I think edit-policy is good, and should obviate the need for 
> an explicit "owner" of the policy.

Agreed, although we may need similar restrictions to those we have on
group co-ownership (i.e. people have edit access to policies they create
by default, and you can't remove the last policy co-owner).

>> switch-policy refers to changing the access policy on a system to a
>> different policy. If we don't add it, updates would be limited to the
>> system owner.
> 
> I'm not sure this makes sense. It feels like escaping the permission 
> system. In any case, I think we could safely defer it for now.

Agreed.

>> schedule-explicit gets us back to the notion of having systems in the
>> general pool that are available to the scheduler, but only when
>> explicitly requested in the job XML. This extra field would allow you to
>> have a policy where "schedule-recipe" was empty (so the system would
>> never be used automatically), but we could add new features to the job
>> XML to override the normal rules. Since there would need to a lot of
>> other supporting changes to make this happen, it should be a deferred
>> feature, but it's something to keep in mind as a future enhancement that
>> may guide the underlying implementation details.
> 
> I think "schedule-explicit" is an interesting idea but it's really 
> orthogonal to the access policy. It's more about what kinds of 
> reservations the system will allow: so, not *who* is permitted to 
> reserve, but rather *how* they are permitted to reserve it. We are 
> already using the Condition field (Broken, Automated, Manual) for that. 
> There is also the Type field which serves a similar purpose (requires 
> explicitly opting it to the system) but by a completely different 
> mechanism. So I think these need to be generalised/simplified rather 
> than adding yet another different mechanism through the access policy.

Yeah, I'm thinking that the initial "system pools" design was really two
concepts masquerading as one, which is why it felt confusing.

With access policies separated out as their own thing, then we can focus
on designing system pools as a scheduling tool, and more closely
scrutinise how it overlaps with Condition and Type.

Cheers,
Nick.

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

Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/)


More information about the Beaker-devel mailing list