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

[Michael DeHaan]

>
> 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 at redhat.com 
> <mailto:mdehaan at redhat.com>> wrote:
>
>     Michael DeHaan wrote:
>
>         Slinky wrote:
>
>
>
>             On 31/03/2008, *Michael DeHaan* <mdehaan at redhat.com
>             <mailto:mdehaan at redhat.com> <mailto:mdehaan at redhat.com
>             <mailto:mdehaan at 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 at redhat.com <mailto:et-mgmt-tools at redhat.com>
>     https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>
>
>
>
> -- 
> Regards
> Dan
> ------------------------------------------------------------------------
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools