The history user permissions problem: Quickfix

[xs-]

---- Edit
This only applies to postgresql!
It seems that postgresql (probably oracle to) and mysql differ how they handle NULL values in an SQL sort.
Users using MySQL will not benefit from this!
---- end of edit

Hi,

In the webfrontend for 1.4.4 i have found the following problem:

Situation:
- Normal user (no admin)
- User has access to GROUPA but not GROUPB
(not an explicit deny, just not defined)
- Hosts belonging to GROUPA and GROUPB
- Hosts belonging to GROUPA only

Symptoms:
- Now the user can see trigger overviews, data views, latest data, etc of servers in both groups.
- The user can see item history (text and graph) of hosts in GROUPA only
- The user can't see item history (text or graph) of hosts in GROUPA and GROUPB. 'ERROR: No Permissions'

finding the problem
After searching through the php code and trying some of the queries, i found out that the result set in the above situation is . . . less desirable.
history.php fetches two lists (i wont bash on the spelling

$denyed_hosts = get_accessible_hosts_by_user(blah);
$availiable_hosts = get_accessible_hosts_by_user(blah);

The item's host is in both lists, which is bad because the permission check is done on $denyed_hosts.

The function get_accessible_hosts_by_user(); resides in includes/perm.inc.php which queries the db for the user permissions crossing all user groups.
Looking at the db result set for the $denyed_hosts, you will get something like:

Node; Nodename; Hostid; Hostname; Perm; Userid
1; "node"; 100100000010175; "host1"; ;
1; "node"; 100100000010175; "host1"; 2; 100100000000006
1; "node"; 100100000010188; "host2"; ;
1; "node"; 100100000010188; "host2"; 2; 100100000000006

Because this is sorted DESC on perm and userid, the host entries without perm and userid come up first and thus showing up in the $denyed_hosts list/

Quick fix
I *think* the permissions query isn't meant to produce the above resultset.
I've tried to rewrite the query several times in order to get a result set with the correct records only, but each time i fixed the user permissions i broke the admin part.
The only working 'hack' i got working without breaking other parts is modifying the sort order for perm and userid in the query (as described above), thus making the correct host entry show up first per host.

Diff for includes/perm.inc.php

172c172
< ' order by n.name,n.nodeid, h.host, permission asc, userid asc';
---
> ' order by n.name,n.nodeid, h.host, permission desc, userid desc';

@zabbix developpers
Can you confirm this issue and that the above fix doesn't break other parts of the web interface? All seems to be working after this but hey, its the perm.inc.php.
If the fix is workable, i hope it will be included so this problem wont occur in future releases.

[theologu]

Hello,

Your hack is working, thanks....

The problem is that is much work from developers to configure fully working authentication as supposed. Lucky for us that this hacks exist and makes life easier

[kassec]

This fixed my user rights problem on 1.4.5.

[Aly]

I haven't checked this patch yet, but as I understand this patch makes an items belonging to several groups with only 1 group accessible be visible to user?! It's wrong, if user doesn't have permissions to any item's host, user shouldn't have permissions to see it!

[kassec]

I haven't checked this patch yet, but as I understand this patch makes an items belonging to several groups with only 1 group accessible be visible to user?! It's wrong, if user doesn't have permissions to any item's host, user shouldn't have permissions to see it!

2 points here :

- On the user right screen, if I have a host belonging to several groups and I add one of those groups for a user, then all hosts from this group appear as allowed for the user. Looks like this is the base logic.

- My case is even worst than that. My user has rights to *all* groups the host belongs to. Before the patch, my user can see data & triggers from the host but can't have access say to the 500 latest values from a data item. Nor to any graph. After this hack, my user has access to simple graphs, data history, complex graphs, screens and slideshows. This is what I want.

I just did something dumb here : copy/paste. I didn't tried to really understand the logic. I had a bug, it vanished with this hack. Cool


Edit:
My user doesn't have access to all groups. Some servers are also attached to another admin group.

[xs-]

I haven't checked this patch yet, but as I understand this patch makes an items belonging to several groups with only 1 group accessible be visible to user?! It's wrong, if user doesn't have permissions to any item's host, user shouldn't have permissions to see it!

No, this is a dirty quickfix for a problem which occurs when a server belongs to <n> groups but a user only has permissions to <n>-1 of those groups.

The perm.inc.php query wich is described, returns a too large and messed up result set. The fasted (but dirty) way to fix this is to modify the sort order which causes the permission calculation to pass correctly in the described situation.

[Aly]

No, this is a dirty quickfix for a problem which occurs when a server belongs to <n> groups but a user only has permissions to <n>-1 of those groups.

Because of this -1 user does not have permission to the server. It's not a bug. Or, am I missing something?

[xs-]

As stated in post nr1 (small changes to improve scope):

- User has access to group GROUPA
(no permissions defined for group GROUPB thus no permissions)
- Host HOST1 belonging to group GROUPA and group GROUPB
- Host HOST2 belonging to group GROUPA only

In this situation the user has broken permissions for HOST1, HOST2 is working fine.
The cause of this is one of the queries in perm.inc.php.
Create the above scenario and test for yourself.

You will see the problem when you run the query in perm.inc.php line 165 by hand (on postgresql in my case) in the given situation. You will multiple results per host for the queried user. this is ugly imho but thats not the point. The actual point is that because of the default sorting the record containing the lowest permission is used, thus breaking permissions.

[kassec]

Because of this -1 user does not have permission to the server. It's not a bug. Or, am I missing something?

Currently, there is a bug, it's sure. If you think user must have permission to ALL groups the server belongs to, then there is bug because user can access data & triggers by only having rights to *one* of the groups a host belongs to.

But, AFAIK, currently it should work the other way : user only need rights to *one* of the group to get access.

Imagine a server belongs to group "admin", "email" and "web". Sysadmins have all their critical servers under group "admin". Webmaster has access to group "web" because he has applications running here. But Webmaster does not have rights for group "email" nor "admin". There are other servers in those groups that Webmaster should not be able to access to. If I follow you, you mean Webmaster can access web servers just because they also belong to some other groups ?

For now, when I select user rights, I only need to give access to one group for the servers belonging to that group being added to the list of authorized servers for the particular user I'm editing.

The bug on the other side : when a user has access to data and triggers, then he/she should also have access to graphs, screens and slideshows.

[Aly]

As stated in post nr1 (small changes to improve scope):
Quote:
Originally Posted by xs- View Post
- User has access to group GROUPA
(no permissions defined for group GROUPB thus no permissions)
- Host HOST1 belonging to group GROUPA and group GROUPB
- Host HOST2 belonging to group GROUPA only
In this situation the user has broken permissions for HOST1, HOST2 is working fine.
The cause of this is one of the queries in perm.inc.php.
Create the above scenario and test for yourself.

You will see the problem when you run the query in perm.inc.php line 165 by hand (on postgresql in my case) in the given situation. You will multiple results per host for the queried user. this is ugly imho but thats not the point. The actual point is that because of the default sorting the record containing the lowest permission is used, thus breaking permissions.
Reply With Quote

ok, I have looked closer on the issue and yes, you are correct. But I still need to figure out for what purpose it was made like that. When I find out I'll write back.

[Aly]

The bug on the other side : when a user has access to data and triggers, then he/she should also have access to graphs, screens and slideshows.

If they contains only items from accessible hosts.. As I sad, I need more time to investigate situation with denied hosts

[xs-]

@Aly
Well, that was my point in the first post, i dont know why the resultset is returned like that, and the only safe thing i could do (without breaking other parts of the webinterface using that function) was change the sort order.

[xs-]

(bump, I have updated/edited the first post a bit also)

The described problems in the first post only apply on the 1.4.4+ webtree in combination with postgres (and possibly oracle).
It seems that mysql and postgres differ in the way they sort (ORDER BY <bla> DESC/ASC) NULL values.
Because of this, the described problems do not occur on a zabbix frontend using mysql, since the resultset is sorted correctly here.

We recently migrated from postgres to mysql and i had to rollback the changes to perm.inc.php

@devs
Can you look into this for future updates?

[Aly]

We already aware of this The changes are committed to SVN.

P.S. SQLite sorts as MySQL

[richlv]

We already aware of this The changes are committed to SVN.

is this the same issue as http://www.zabbix.com/forum/showthread.php?t=7193, http://www.zabbix.com/forum/showthread.php?t=8997, http://www.zabbix.com/forum/blog.php?b=30 and reported at https://support.zabbix.com/browse/ZBX-87 ?
is it really fixed ? is that revision 5599 for 1.4 branch ?
that would be awesome, it is (or was) a quite old issue...