[Beaker-devel] Some thoughts on system access policies

Nick Coghlan ncoghlan at redhat.com
Wed Jul 31 01:39:46 UTC 2013


Putting these thoughts in email form so Dan can either take them into
account when rewriting the system pools proposals, or else suggest areas
which seem like unneeded complexity. For example, with ad hoc groups,
maybe we don't need system pools as a separate notion for tagging
purposes (just create a group instead). They're all only half-formed
notions, so definitely take them with a rather large grain of salt :)

Firstly, I'm thinking that we should ensure the system <-> access policy
relationship is always one-to-one. Anything else will be too confusing.
If we decide to later implement a tagging system for referring to kinds
of systems, that should be a separate thing independent of access policies.

I'm contemplating up to four different "kinds" of access policy:

- system access policy. Just a transition mechanism from the current
system level permissions, these will be created automatically as part of
the data migration from the legacy access model. These would be
represented in the UI as a "Custom access policy".

- user access policy. The default access policy applied to systems owned
by a particular user if no other policy is nominated. Can only be edited
by the user themselves.

- group access policy. An access policy controlled by the owners of a
particular group. System owners may switch the access policy from an
implicitly created system policy or their user policy over to a group
access policy.

- pool access policy. An access policy independent of any particular
group. In a certain sense, system access policies are an example of
this, using a pool containing exactly one system.

As part of this, I'm wondering if we want to borrow the *nix account
management notion of creating an implicit group for each user, where
they're the group owner and only member. Then we can require that access
policies have an "owning group", and for user access policies, this
would be the user's implicit group. Similarly, for custom access
policies, the policy owner would be the system owner's implicit group. I
suspect there are trade-offs either way (modelling user-owned policies +
group-owned policies separately, or introducing an implicit group for
each user), but it's something we should deliberately consider.

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)

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)

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.

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.

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