Hi, I am currently trying out the permissions for Icinga DB Web and I am a but confused whether this is the desired behavior or if I should open a bug.
If I create two roles, both restricting the user to not see certain custom vars, the result is that only the intersection of those two restrictions will be applied.
For example if roleA has a restriction on *password* and roleB has a restriction on *token*, then a user with both roleA and roleB can see all variables, except those containing BOTHpassword and token. So api_password or jwt_token are visible, only e.g. password_token would be really hidden.
The same goes also if roleB would inherit for roleA. Unless roleB copies all the restrictions from roleA before adding new ones, it will be ignored.
When looking at the audit functionality of icingaweb2 however, it will show the permissions as *password*,*token* which in my opinion is the much more sensible approach, so that you don’t accidentally leak information because two roles don’t have overlapping restrictions.
Both roles express basically: NOT *password* OR NOT *token* api_password matches with NOT *token* and jwt_token does with NOT *password*. password_token however does not match at all and is hidden as result.
Restrictions from multiple roles are always combined this way. That is also documented:
Restrictions are expressions that limit access. What this exactly means is up to how the restriction is being utilized. Without any restriction, a user is supposed to see everything . A user that occupies multiple roles, which all define a restriction of the same type, will see more. Security - Icinga Web
To achieve what you want, you need to define the protections in a single role. A base role for example.
Are there any plans to bring back the Security tab? I want a feature to assure that what you see is actually what you get. I don’t feel comfortable adding it to a role, if any other role might break the rules, without carefully reviewing all other roles to make sure none overlap with mine for any users…
