Users with Director restrictions unable to create hosts unless you manually specify the host group

[0xliam]

Expected Behavior

A user should be able to create a host that would result in that host being included in a host group, without having to manually specify the group.

Currently, if a user in Director has host group restrictions, they are unable to create a host unless you manually specify a group the user has access to.

Current Behavior

If a user has a host group restriction in Director, and that host group is defined with an assign-where rule, a user can't create a host that would match that assign-where rule.

Possible Solution

Steps to Reproduce (for bugs)

Create a role with a host group filter - e.g.:

Restrictions: director/​filter/​hostgroups = customer.org.au

Create a host group in Director with an assign rule - e.g.

object HostGroup "customer.org.au" {
    display_name = "Customer A"
    assign where host.zone in [ "customer.org.au" ]
}

Create a new host in zone customer.org.au.

When a user saves the host, the save errors with: Unable to store a host with the given properties because of insufficient permissions (IcingaHostForm.php:373).

However, if you then add the host to the customer.org.au host group manually, a user is able to save the host.

The host would be included in the customer.org.au host group, but because it has not been created yet, the rule is not applied, and therefore permission is denied.

Your Environment

• Director version (System - About): 1.11.1
• Icinga Web 2 version and modules (System - About): 2.12.1
• Icinga 2 version (icinga2 --version): 2.14.2
• Operating System and version:
• Webserver, PHP versions: 7.4.33

This seems similar to https://github.com/Icinga/icingaweb2-module-director/issues/1663 - but is a slightly different use case. I'm not sure if this is intended behaviour, but essentially a user cannot create a host that would end up being included in an apply rule they are allowed to access.

If this is intended behaviour, perhaps the message should be updated to inform the user that they need to specify a host group they are allowed to use.

[0xliam]

I've encountered another issue which may be related to the way permissions and host groups are evaluated - when a user adds a host to a host group, the direct memberships appear to prevent assign memberships from being evaluated.

Using the example host groups above, assuming there are some hosts that already exist in Director in the customer.org.au group - if a user then adds a host directly to the group, the hosts that were originally included by the apply rule are no longer evaluated in the Director view, and therefore the user loses access to the hosts.

However, this only affects Director - everything works as expected in Icinga DB and the monitoring module.

[slalomsk8er]

Maybe I have the same problem. @0xliam can you check if the apply rule works if you change something else, like the note field and save the host?

In my case I have users clone a host and then getting a error that they aren't allowed to see there new host in the director. The group is defined in a import. This also happens, when I clone the host for them, the host isn't a member of the group, until I change something else on the host and the group membership evaluation is triggered.

[nilmerg]

ref/IP/53158

[nilmerg]

We'll investigate this when working on v1.12.