If the setuid option comes in though, we like this a lot. It means we
start to move away from cobbler running as root....
Here's a third simpler design option for a non-root command line that
may not require remoting... I'm a big fan of letting the OS
do the work when possible so this may be a good idea.
-- Set up ACLs for users that need to get access to cobbler data. We
can come up with a script to do this.
-- Do not set cobbler up as setuid/anything, have it run as whatever
user runs it
-- Have the cobbler binary ask the OS for the logged in uid/username,
and use authorization rules based on that (such as ownership).
-- In this case, the OS could use whatever facility it wants for
authentication of user accounts.
We still need to kerberize the web services though for those who aren't
satisfied with the LDAP method, but this allows
you to have ownership and multiple users getting at the cobbler command
line as non-root, and you could choose your OS
authentication mechanism to be anything you want (including
kerb/LDAP/NIS). Make sense? This would
be relatively simple, and since the default authorization policy is
"allow all", it works out of the box without the user
having to configure anything.
The command line can easily check to see if the user has access to the
files in question and would report if ACL's are not set up right.
Should be pretty close to what we want...
--Michael
On 01/04/2008, *Michael DeHaan* <mdehaan@xxxxxxxxxx
<mailto:mdehaan@xxxxxxxxxx>> wrote:
Michael DeHaan wrote:
Slinky wrote:
On 31/03/2008, *Michael DeHaan* <mdehaan@xxxxxxxxxx
<mailto:mdehaan@xxxxxxxxxx> <mailto:mdehaan@xxxxxxxxxx
<mailto:mdehaan@xxxxxxxxxx>>> 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@xxxxxxxxxx <mailto:et-mgmt-tools@xxxxxxxxxx>
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
--
Regards
Dan
------------------------------------------------------------------------
_______________________________________________
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
