Include implicit filters for ACL roles with administrative access

[mocdaniel]

Describe the bug

Consider the following situation:

A user is member of three roles

• icinga-admin with no filters set for icingadb/filter/hosts, but administrative access for the IcingaDB module
• database-admins with a filter set for icingadb/filter/hosts: host.vars.group_view=database
• incident-prio1 with a filter set for icingadb/filter/hosts: host.vars.prio=1

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

• Icinga Web 2 version and modules (System - About):
  • Icingaweb2: v2.12.1
  • IcingaDB-Web: v1.1.1
• Web browser used: Edge
• Icinga 2 version used (icinga2 --version): 2.14.0
• PHP version used (php --version): 7.4.33
• Server operating system and version: RHEL 8

[mocdaniel]

ref/NC/773667

[nilmerg]

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

[mocdaniel]

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:

• incident role, which may acknowledge every host (hence without a filter)
• db-admin role, which may administrate every DB host (with a filter on some prerequisite)

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.