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

[Michael DeHaan]

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)

----

(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.

---

(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