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