One of the features I want to address for the next major version of
cobbler is this:
I want to present a simple control panel that allows users who own
systems (when using the ownership module) to access to only what they
control. This means rather than an admin to manipulate Cobbler, we can
let the users do what they want to do directly -- the ownership module
does this /almost/ but it's still not quite there.
Lots of folks have asked for similar things (and some are building
similar things of their own, using the Cobbler XMLRPC interface, which
is great), so I wanted to talk about them here to make sure I'm building
what everyone can use.
See
https://fedorahosted.org/cobbler/wiki/CustomizableAuthorization for
background info.
With this module, a user who is not in the admin group can only
manipulate objects that they "own". Any object in cobbler can be
tagged with ownership requirements with "--owner", and an object can
have multiple users/groups being able to edit it.
I think to do this right, we need a third module in modules.conf, that
extends authorization, for handling of where ACL data comes from.
Since each user must already be in a group, all we have to do is define
the ACLs for the group. Tentatively this would be
/etc/cobbler/acls.conf and would look something like:
- whitelist:
- admin:
- "*"
- users:
- "*/*"
- blacklist:
- users
- "distro/set_distro"
- "system/set_mac_address"
- "system/set_ip_address"
- "system/set_hostname"
That's just a simple list of what they are allowed to do, blacklists
executed first.
With wildcards to define what users could and could not access. The
stock cobbler ACL's file would be generous and allow full access with
any ownership module. In addition, whether ACLs were enabled or not
would be a setting in /etc/cobbler/settings and the source for the ACL
data would be in /etc/cobbler/modules.conf, the default would be
"acl_configfile", though it would allow for someone to source ACL's from
other sources by writing their own module.
How does this sound?
Once all of this is done, we would then have a Cobbler webapp that knew,
if ACL's were enabled, only to present objects to the user that they
could edit. Depending on how ACLs were configured, this may allow for
creation of new objects of certain types, or it might not. When
visiting the web page for certain objects, certain fields would then
become not editable, depending on whether the user had rights to edit
those fields, and we'd do something like a "show all fields" button to
hide most of the fields the user could/couldn't edit.
I suspect the percentage of users that would enable this would be small,
but that a lot of the people that do enable this are some of the larger
cobbler installs, so it seems to make sense.
(I also should acknowledge that the security section of the Wiki is
definitely do for some reorganization -- each of the modules should be
indexed seperately so they are easy to find, and right now authn/authz
is a bit mixed up, so I'd imagine plenty of folks aren't aware of what
all the capabilities are. I'll sort this out).
Thoughts?
--Michael