On 08/12/2009 05:07 PM, Paul Company wrote:
> So how do I do the following:
>
> Allow users (i.e., pcompany)  listed in [admins] to do everything,
> but for everyone else (i.e., user2)
> allow
>     list on distros, profiles, repos, kickstarts
> deny
>     everything else (copy/modify/new/remove/save) on distros, profiles,
> repos, kickstarts
> allow
>     everything (list/copy/modify/new/remove/save) on systems
>    

For example, the following prevents edit/save operations on all objects 
from users outside admin.

# cobbler distro list | xargs -n1 --replace cobbler object edit 
--name={} --owners="admin"
# cobbler profile list | xargs -n1 --replace cobbler object edit 
--name={} --owners="admin"
# cobbler repo list | xargs -n1 --replace cobbler object edit --name={} 
--owners="admin"

Kickstarts aren't objects right now, so they don't have ownership, but 
there is logic to say that to edit a kickstart you must
have permissions to edit all profiles and systems that use it -- this is 
a bit goofy, IMHO, but we don't have pseudo objects
wrapping kickstarts and snippets, and I'm not sure we want them.

It doesn't control who can reposync/sync/etc... which is I think what we 
want to work out, how we want that to work.
acls.conf is a little rough....

We might make it so only that admin group users can edit 
kickstarts/snippets as well.    We really do have the opportunity to figure
out exactly what we want to do here, beyond what we have, in trying to 
make this more self service.

The idea behind acls was eventually to have it fine grained enough to 
say what /fields/ someone could access -- if you can edit a MAC, you can 
effectively
make a system represent another physical system, which is crazy bad, 
because if there isn't already a system with that record there, you can 
reinstall
that system.

Thus the permissions system in Cobbler is very much "shoot foot" 
protection versus a really hardcore security system, and various folks 
who are using
it more of a self-service apporach have written their own systems/views 
on top of it.

I think, moving forward, I would like to see those self-service views 
implemented in Cobbler proper.    Doing so on top of the acls.conf 
system would
hamstring our ability to do what we /really/ need to do (whatever that 
is), which is why I think we need to break from it.

However the idea of ownership is still important, and will stay.  We 
just have to figure out that, without the ACLs system, exactly what we 
want to do
with the non-edit actions, as there are now a lot more of them.

FWIW, all of cobbler is public in terms of read access, and this /can't/ 
be locked down (because by the very nature of installation, this data is 
eventually
public, and we don't attempt to obfuscate that).

> I'm a bit confused.
>
> Seems like I shouldn't use acl.conf for many reasons (unsupported,
> will not be in 2.0, etc.).
> How do you disable using acl.conf?
>    

acl.conf in stock configuration really doesn't do anything, so you can 
just leave it as is.

> Paul
>
>    

_______________________________________________
cobbler mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/cobbler

Reply via email to