I've updated this to reflect current plans

https://fedorahosted.org/cobbler/wiki/AclFeature

A sample version of the ACL config as documented above is:

(Again, this is a list of fields/methods to deny access to)

---
admin: {}  # no denials
admins: {}
jradmin:
    copy_distro: *
    copy_image: *
    copy_profile: *
    copy_repo: *
    modify_distro: *
    modify_image: *
    modify_profile: *
    modify_repo: *
    new_distro: *
    new_image: *
    new_profile: *
    new_repo: *
    remove_distro: *
    remove_image: *
    remove_profile: *
    remove_repo: *
    write_kickstart_templates: *
lesstrusted:
    copy_*: *
    modify_distro: *
    modify_image: *
    modify_profile: *
    modify_repo: *
    modify_system:
        gateway-*: ~
        hostname-*: ~
        ip-address-*: ~
        mac-address-*: ~
        subnet-*: ~
    new_*: *
    remove_*: *
    rename_*: *
    save_distro: *
    save_image: *
    save_profile: *
    save_repo: *
    sync: *
    write_kickstart_templates: *
unmatched: {}


Basically that's just denials of various fields.   This should be easy 
to show in the WebUI when someone logs in what they can and can't 
tweak.    Combined with a toggle option in the webapp for "Hide Advanced 
Fields", and also grey out systems people don't own or fields they can't 
access this seems to be rather workable and not terrible to implement.  
Ideally we have a way a  toggle on the list view to list things I own or 
to list all things.

So the question to you is (and I've kind of asked this before), what 
sort of user restrictions and roles would you want in Cobbler?

Does that kind of denial system seem to make sense?

This doesn't preclude having an ACL editor in the Wiki for admin users, 
but I don't plan to write one.   The goal here is to make things very 
workable for folks with specific use cases now, which they'll probably 
set up once and leave alone, rather than building a large 
overcomplicated web system.

The end goal is to be able to hand your cobbler web app to users who 
just need to tweak certain things and feel complicated they won't blow 
something up.... being able to delegate basic installations to users, 
and allow them to control just certain aspects of the configuration 
without breaking too much.

In the most extreme use cases (very large sites) you will probably still 
want to implement your own view into Cobbler's XMLRPC, in which case 
this feature can still be used to enforce security for those communications.

Anyhow, comments welcome.  If you'd rather have something different, 
now's the time to say that too.   If this feature is not for you, don't 
worry though, as it is optional and not in your way by default -- but I 
would never much like to hear from people who do want ACL controls and 
to know if that's the kind of access control they are looking for.

Thanks!

--Michael


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

Reply via email to