Group Rights Precedence?

[js1]

Do read-only rights take precedence in Zabbix? I'm trying to configure our Zabbix deployment with a read-only user group that all admins would be a member of. Then have other limited read-write user groups that admins would be members of.

User1 is a member of ro_group and rw_group1

However, it appears that the ro_group permissions takes precedence. So, even if rw_group1 gives me read-write access, I'm not able to create hosts or other host groups because of ro_group.

Is there a way to do what I'm trying to do? Or, do I need to explicitly add each host group into the read-only rights of rw_group1? This can become an administrative headache if there are many rw_groupN and many host groups.

Thanks for any tips.

[Artturi]

Hello,

I face the same issue. I'm curious to know how other people handle this situation...

Regards,
Artturi

[mgoodman]

Still a problem in 1.8.4...

Yeah, it is kind of ridiculous -- it makes the user groups essentially useless, especially in a matrix engineering environment.

It should be re-written around a better security model, such as on with the following options:
- read-write
- read (NOT read-only)
- deny

Default permissions would be to deny access if nothing is explicitly set (e.g. even if deny is not selected, but neither are read-write or read, they get denied).

For example:

- If someone is in a group which has read-write, they would be granted read-write.

- If someone is in a group which has read, they would be granted read.

- If someone is in two groups, one group which grants read-write and another group which grants read (over the same thing), they get read-write.

- If someone is in two groups, one group which grants read-write (or read) and another which is set as explicit deny, they get deny.

This allows you the security of default deny, the flexibility of multiple groups and choosing the more appropriate permissions, and the additional security of an explicit deny trumping everything.

Group permissions as they are, honestly, are useless. May as well just assign permissions on a per-user basis instead, for all but the simplest of environments.

If someone needs some help modifying the code as such, please let me know...

[Alexei]

Default permissions would be to deny access if nothing is explicitly set (e.g. even if deny is not selected, but neither are read-write or read, they get denied).

For example:

- If someone is in a group which has read-write, they would be granted read-write.

- If someone is in a group which has read, they would be granted read.

- If someone is in two groups, one group which grants read-write and another group which grants read (over the same thing), they get read-write.

- If someone is in two groups, one group which grants read-write (or read) and another which is set as explicit deny, they get deny.

That's exactly how Zabbix permissions work if I do not miss anything in your post.

[mgoodman]

That's exactly how Zabbix permissions work if I do not miss anything in your post.

...unfortunately, no.

Currently, read-only permissions override read-write permissions.

In fact, it should be rewritten to be a simple read permission option, not read-ONLY permission option (implying that it will deny write). That way, you can select read-write AND read, and still have the ability to read-write. Understand?

[mgoodman]

to clarify

just to clarify, it's the third scenario that doesn't work as expected in Zabbix:
- If someone is in two groups, one group which grants read-write and another group which grants read (over the same thing), they get read-write.

Currently, they would get read-only, because there is only the option for "read-only" not simply adding "read" privileges.

[sire]

Creating a bug report may help solve this issue faster https://support.zabbix.com/secure/Dashboard.jspa

[mgoodman]

it's not a bug, per se

I would -- except that it isn't a bug. It is, however, a feature request. I'm not sure where to submit requests for features, or suggestions to improve design. I'd also like to contribute somehow...if you could lead me to where to go for this that would be great.

Thanks,
Michael

[sire]

Feature requests can be created at the same page, just choose issue type "New feature".

[Alexei]

Currently, read-only permissions override read-write permissions.

You are right. I believe that overwriting RO with RW has more practical value, however I do not think it should be changed in 1.8.x.

[mgoodman]

Thanks Alexei. Is this slated for the 2.x release? I'd understand not backporting to 1.8.4 if 2.0 incorporates it and is near on the horizon. =)

-Michael

[richlv]

adding to 1.8 would not be desirable as this is a quite significant change in how permissions operate, and thus security related.

i've personally discussed this multiple times, and it seems to mostly make sense to have r/w override r/o.
a counterargument might be that "lower" permission always overrides a "higher" one - deny -> r/o -> r/w.

i'd love to hear more opinions on this

[mgoodman]

Right, I'm all about strict security as well. However, if you have RW override RO, then you can STILL have an explicit DENY, which would override everything. If you really want to get granular, which I doubt is useful for many environments, as the users are generally admins anyway, there could be a fourth option of forceful RO, where this would override RW. So basically you get:
- deny (default behavior if nothing is set)
- RO
- RW
- forceful RO (overrides RW)
- explicit deny (overrides everything)

The rules at the bottom of the list override the rules higher up the chain, as you can see. RO overrides default deny, RW overrides that, forceful RO overrides that and explicit deny overrides that. With that model you should be able to do anything you want.

A bit complicated though. Might be easier to just have a flag in the admin section to change default behavior (RO overriding RW) to have RW override RO, albeit it isn't as flexible.

[richlv]

see also :

http://www.zabbix.com/forum/showthread.php?p=63274

https://support.zabbix.com/browse/ZBXNEXT-887

[Alexei]

We've been discussing it this week. Conclusion: the feature won't be included into 2.0.