About the permission / rights system

[xs-]

Hi all,

First of all, the following is how i an personally experiencing things, and i could be wrong in making several assumptions, please correct me if I'm wrong.

Although this changed somewhere in the 1.4 tree (1.4.5 or 1.4.6) i didn't think it would be used in 1.6. As it is, i am wondering why and looking for some more info on the subject. Perhaps I'm missing the whole point of the change.

Situations
I am talking about the user types and permissions (RO/RW on hostgroups and nodes).
In 1.4 (except 1.4.5 and 1.4.6 i think) the behavior was as follows:

• User
  A normal user for accessing normal system content.
  Depending on the permissions (RO/RW for hostgroups) this means viewing collected data or viewing / altering hosts / items / triggers.
• Admin
  A user with elevated privileges which can manage all normal system content plus configuration of the system itself, with the exception of dangerous and permissions configuration (i.e. user/group and node).
• Super Admin
  Like admin but can configure everything

Furthermore, when setting group permissions, you could grant RO/RW/DENY rights to hostgroups and nodes.

Now in 1.6 (+-1.4.5) some things changed, and this method apparently is used in 1.6.

• UserNormal user which can only view information, not change (configuration menu never shows).
  Whats the point of RO/RW rights here anyway? the normal monitoring view has no fields to mutate.
• Admin
  This looks more like the normal user in 1.4.4 and before. Configuration menu is available for Admins but only hosts(groups) show up where the user actually has RW permissions for. No administration panel.
• Super Admin
  Admin user which can manage all system content plus system configuration.

When setting group permissions, only hostgroups can be selected, node selection is no more?

My view on things
IMHO:

• there's nothing wrong with, depending on permissions, a normal user being able to mutate 'normal content'.
• What happened to the node permissions? Ok, it didn't work when it was selectable, but the idea is great. Grant write permissions to a user (for managing all that node's content) or admin (for managing node configuration, aka admin panel).
• I kind of liked the old difference between admins and super admins (user / node management limited to a few, normal admin privileges to the rest of the admins).

So to sum up:

• User should be able to configure content (hosts/hostgroups, items, triggers, etc) depending on permissions.
  • RW on hostgroup: configure hosts (not delete). Things like disable hosts / items / triggers (for maintenance etc), create new items / triggers, etc.
  • RW on node configure all content on the node.
• Bring back nodes in the permission selection (so its hostgroups AND nodes).
• Restore normal Admin functionality in combination with the node permissions, but keep dangerous stuff to super admin (like user/group and node management).
  • DENY on node: no admin menu
  • RO on node: access to most of the admin panel but no changes
  • RW on node: access to most of the admin panel incl changes

Sorry for the long post, i tend to babble a lot

[Aly]

1. Yes, you are correct, RW permissions for simple user are useless.
2. Simple user haven't had permissions to configuration in 1.4.x, so he couldn't change anything.
3. Mostly, permissions are the same, excepting:
3.1. user admin by default doesn't have permissions RO&RW to all host-groups by default.
3.2. If host linked to several host-groups with different permissions, the lowest permission is picked up.
4. Node permissions now based on node:host-group permissions.

[xs-]

Thank you for your response.

I hope this isn't the final 'version' of the rights system tho, i would like to be able to use a little more fine grained access.
(oh, the early 1.4 tree could do normal user rw in configure).

I would like to be able to setup the following types of users (regardless of the type). If this is currently possible i'd like to know how, i don't see any way of doing this. Plus the changes to make this possible seem relative small (though i could be wrong ofcourse )

• Host/hostgroup admin
  • RW on a host / hostgroup for i.e.
    disable/enable on host/item/trigger
    change values or update comments on stuff
    acknowledge events
    (un)link templates to allowed hosts
  • Not allowed to create new things or modify node configuration, i.e.
    not create new hosts / hostgroups / etc
    not change valuemaps, housekeeping, actions, discovery, import/export, etc
  
  This could be easily achieved if a normal user has RW rights and have access to the configuration panel (but with limited 'user' access)
• User with global RO /RW rights (either admin or user)
  • A normal user (i.e. service manager) with global read rights is very hard to manage, because you need to grant individual hostgroups (endless clicking in the GUI) and whenever new hostgroups are added, these also need to be added to a 'global' user. Yes this can be done with a usergroup, but its unmanageable.
  • Same goes for normal user with global RW, and admin with global RW. We have about 90 hostgroups (and growing), which are mostly related to departments / customers.
    Within our staff we have people who require a global 'host management' role, and people who require a 'global admin' role. Small note, 'global admin' is something different from super admin. Super admins manage zabbix itself, which is a bit too much for a global admin if you catch my drift.
  
  This could be easily achieved if besides hostgroup permissions, the node permissions also is available. This goes for normal users and admins.

[Aly]

As far as I know, we are not planning to add any new user roles. But may be Alexei have another view on things...

IMO:

I agree, that previous permission scheme haven't required adding every new host to RO&RW for admin users via they had permissions to it by default. But when you create file on linux you need to chmod it.. Why? because this way it's more secure and more flexible.

Granting access for user-group in GUI should be improved with no doubts.

[teferi]

As far as I know, we are not planning to add any new user roles. But may be Alexei have another view on things...

IMO:

I agree, that previous permission scheme haven't required adding every new host to RO&RW for admin users via they had permissions to it by default. But when you create file on linux you need to chmod it.. Why? because this way it's more secure and more flexible.

Granting access for user-group in GUI should be improved with no doubts.

Alternatevly you can set umask, to create all files the way you like conviniently. Any ideas on such "umask" for zabbix?

[krimson]

I would like to add that this new rights system generates a problem for me. I have a zabbix service running where multiple teams need to maintain their own servers. So I give them Zabbix admin rights and bind them to the hostgroup(s) they are responsible for. I was a little surprised that they can now also modify things like Actions. My assumption was that only a Zabbix super admin (me ) would be able to modify this.

Will this be changed in the future ?

[jamesh]

I was a little surprised that they can now also modify things like Actions. My assumption was that only a Zabbix super admin (me ) would be able to modify this.

Agreed...this is a huge hole. Admins being able to modify/delete/disable actions that respond to triggers outside of their realm basically makes them a Super Admin.

[jamesh]

It limits flexibility when assigning host and user groups but you can exclude access to specific actions to certain users if you add a host group condition to each action that is outside of the user's authorized host group(s). Hope that made sense.

[xs-]

Thats exactly why i'm proposing to grant a user RW permissions that will allow modifcation of the hosts/hostgroups and its childs for which the RW perm has been granted.
An admin user should be able to change everything in the configuration screen (the content part from the first post).
The only difference between admin and super admin is the ability to do administrative tasks of the system itself.