Cobbler and the ownership module, question about policies?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux