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 _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
