FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora/Linux Management Tools

 
 
LinkBack Thread Tools
 
Old 03-31-2008, 09:35 PM
Michael DeHaan
 
Default Cobbler and the ownership module, question about policies?

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@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-01-2008, 12:53 PM
Slinky
 
Default Cobbler and the ownership module, question about policies?

On 31/03/2008, Michael DeHaan <mdehaan@redhat.com> wrote:


-slash-


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.**
Will this always been the case? We'd like to see the same ownership model apply to the webui and CLI.



(It's also coded up so you can't use the WebUI to remove
your own access from an object).

^ see above




_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-02-2008, 12:38 PM
Slinky
 
Default Cobbler and the ownership module, question about policies?

I think if we are to deploy Cobbler more, we would create something which allows remote communication to cobbler. It wouldn't care about import or such, just things like add/remove/edit objects like distros/profiles/systems/kickstarts and maybe sync.


The end result would be a "cobbler client" talking to the XMLRPC interface, using kerberos5 credentials to get access (but at this point I'm not too sure how I can pass my krb credential as a blob to Cobbler for checking with kerberos.


For the moment if we really need the client, we can create somehting using demo_connect and pass the approapriate credentials to ldap, via Cobbler, but in the end we would need authentication as transparent as possibe.


If the setuid option comes in though, we like this a lot. It means we start to move away from cobbler running as root....

Just some mumblings after lunch.

*

On 01/04/2008, Michael DeHaan <mdehaan@redhat.com> wrote:
Michael DeHaan wrote:


Slinky wrote:






On 31/03/2008, *Michael DeHaan* <mdehaan@redhat.com <mailto:mdehaan@redhat.com>> wrote:






-slash-



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

Will this always been the case? We'd like to see the same ownership model apply to the webui and CLI.




Originally I wasn't planning on adding auth to the command line. * Interesting idea.



You could also perhaps get away with making a simple remote command line that only contained the features you needed and used the existing XMLRPC/CobblerWeb code as a basis. * It would have to accept a username and password, possibly from doing something like reading ~/.cobbler.rc or something? * If it didn't have to do things like "import" it would be pretty simple.




There are more complicated alternatives involving ACLs and setuid (non root), but I think I like that solution better.



Thoughts?




Actually the local approach may not be too bad either.



We make cobbler setuid to a cobbler user (not by default, but in this configuration only), set that user up with ACLs on the right places, and turn on a flag in settings that says "require_local_auth". *We make the api module in cobbler make the same calls Cobbler is using for remote if "require_local_auth" is on. *And then we require user/password info when "require_local_auth" is enabled by adding some new arguments or reading a file in "~/" (or something... yes, kerberos is in the running but we must also support /non/ kerberos).


Setup will not be super-trivial, but we could perhaps make a sample script to help people with that configuration. *

I see Dan has this use case, but does anyone else? * I hesistate to add to much to support niche cases, though often these seem to be some of the things larger installs are sometimes looking for.



--Michael



_______________________________________________

et-mgmt-tools mailing list

et-mgmt-tools@redhat.com

https://www.redhat.com/mailman/listinfo/et-mgmt-tools



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

Thread Tools




All times are GMT. The time now is 06:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org