[et-mgmt-tools] Cobbler and the ownership module, question about policies?

[Bryan Kearney]

Michael DeHaan wrote:
> So,
> 
> Warning -- technical email :)
> 
> I have a pretty good ownership module going for Cobbler now 
> (https://fedorahosted.org/cobbler/wiki/CustomizableAuthorization), that 
> allows you to say that objects are owned by certain users and/or groups, 
> and prevents users not in those groups (except for an admin group) to be 
> able to edit those objects.   This is designed for very large 
> organizations that may want lab admins to control certain profiles, but 
> not all of them (for instance, a build lab versus a test lab versus a 
> production datacenter, etc).
> In this implementation, users in the admin group have access to all 
> objects always, and by default all objects are created with no editing 
> restrictions unless the creator decides to lock them down.      The 
> command line has none of these restrictions so you can always 
> recover/reconfigure things with root if you find you've somehow locked 
> yourself out.   (It's also coded up so you can't use the WebUI to remove 
> your own access from an object).
> 
> There are a couple of policy questions for this dealing with some of the 
> corner cases.
> 
> (A) What to do about kickstart editing in the WebUI.   This is the "fun" 
> corner case to figure out.
> 
> The WebUI contains a very basic kickstart template editor (it's just a 
> text field for now). 
> Possible Answer1? I think the solution is that a kickstart template file 
> can be edited if the user editing it is allowed to edit ALL 
> profiles/systems making use of it.  This is a bit of a catch 22 as it 
> would be possible to create a system using a template file, just for the 
> purpose of making that user not be able to edit it.  This shouldn't 
> happen but is technically possible.
> Possible Answer2 -- If you're not in the admin group, you can't edit 
> kickstart template files at all.
> 
> Possible Answer3 -- Remove kickstart editing from the WebUI, and 
> encourage users to create kickstart templates where they have filesystem 
> access (i..e their home directories)

For testing, I have liked the ability to edit he ks file and not need to 
log into the box. If possible, please keep it. It may be heinous, but is 
there a model where each ks has a security item associated to it (e.g. a 
role) or ks files can be grouped and a role associated to the group?
> 
> ----
> 
> (B) What do to about "orphanage".
> 
> If UserA owns ProfileA, and UserB owns SystemB, which depends on 
> ProfileB, what happens if UserA wants to delete ProfileA?
> 
> Answer?   The profile cannot be deleted.
> 
> If UserA owns ProfileA, and UserB owns SubprofileB, what happens when 
> UserA wants to delete ProfileA?
> 
> Answer?   I think the answer is Subprofile B is promoted to a full 
> profile with all of the inherited fields set to the values of Profile A.
> However this is complicated and confusing so "No deletion allowed" may 
> be the better route.

First cut, no delete. Every time i have used nested profiles it was 
becuase I had nested logic in the kickstart file. So. promoting a 
subprofile would cause the subprofile to break.
> 
> ---
> 
> (C) FYI...
> 
> Everyone is allowed to run "cobbler sync" if they can authenticate.  I 
> don't think this should be a problem.
> 
> Also, if you're in, you can read everything, you just might not be able 
> to /write/ everything.   This also should not be a problem as provisioning
> data is basically public if you want to use it in a Fully Automated 
> Context anyway.
> 
> Currently settings, modules.conf, and users.conf can't be edited through 
> the WebUI as that's a really good way to lock yourself out of the WebUI
> altogether :)
> 
> ---
> 
> Any thoughts on the above from those who have a vested interest in 
> controlling access to cobbler objects through the WebUI?
> Remember this is all off by default and is only there if you want it -- 
> but if you want it, I want to make sure this fits your organizational 
> needs.
> 
> --Michael
> 
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools