Icinga / icingaweb2

A lightweight and extensible web interface to keep an eye on your environment. Analyse problems and act on them.
https://icinga.com/get-started/
GNU General Public License v2.0
808 stars 282 forks source link

Include implicit filters for ACL roles with administrative access #5156

Open mocdaniel opened 11 months ago

mocdaniel commented 11 months ago

Describe the bug

Consider the following situation:

A user is member of three roles

The Audit tab of the ACL settings displays the following merged filter for this member:

host.vars.group_view=database|host.vars.prio=1

which results in the user seeing no hosts which he'd be allowed to see due to having administrative access, but don't match the more restrictive filters.

Instead, we have to add a 'dummy' filter for the icinga-admin role, e.g. host.name~*, effectively duping the implicit meaning of having administrative access, changing the composed filter to:

host.name~*|host.vars.group_view=database|host.vars.prio=1

Which intuitively feels like the filter that should've been created in the first place.

To Reproduce

  1. Create three roles as described above in ACL
  2. Add user to those roles
  3. Add at least three hosts, two with customvars as described above, one without
  4. Confirm the user can't see the host without customvars
  5. Add the 'dummy' filter to the icinga_admin role as described above
  6. Confirm the user can now see all three hosts

Expected behavior

A more intuitive way of handling this would be to implicitly add 'wildcard' filters matching every object if no filters are set and the role specifies administrative access.

Your Environment

Include as many relevant details about the environment you experienced the problem in

mocdaniel commented 11 months ago

ref/NC/773667

nilmerg commented 11 months ago

Have you tried whether making icinga-admin unrestricted produces the desired outcome?

image

mocdaniel commented 11 months ago

Unrestricted access works. However, this is only the case because in the scenario above the targeted user is in fact an unrestricted user. Out in the wild, there might well be scenarios where in fact restricted users get different permission sets merged, some of which don't contain any filters, e.g. combinations like this:

Then, again, upon merging the empty filter of the incident role with the filter of the db-admin role, the incident responder would in fact be restricted to DB hosts once again.

Therefore, there needs to be some kind of implicit fallback in case no filter is set, IMO.

The only other possibility would be to make filters required in ACL settings, but this would add lots of work for setups with lots of roles.