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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
