# IcingaDB Web protected vars behavior **URL:** \ **Category:** Icinga DB Web\ **Created:** [June 4, 2025, 2:22pm UTC](https://community.icinga.com/t/icingadb-web-protected-vars-behavior/14904 "2025-06-04T14:22:23Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![w1ll-i-code](https://community.icinga.com/user_avatar/community.icinga.com/w1ll-i-code/32/8526_2.png) [@w1ll-i-code](https://community.icinga.com/u/w1ll-i-code)\ **Post date:** [June 4, 2025, 2:22pm UTC](https://community.icinga.com/t/icingadb-web-protected-vars-behavior/14904/1 "2025-06-04T14:22:24Z")
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 **BOTH** `password` 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. This is caused, because the query for the objects uses a `Filter::any` instread of a `Filter::all` here: [icingadb-web/library/Icingadb/Common/Auth.php at 9080b563a4571a54965603b9f98cbfab64580504 · Icinga/icingadb-web · GitHub](https://github.com/Icinga/icingadb-web/blob/9080b563a4571a54965603b9f98cbfab64580504/library/Icingadb/Common/Auth.php#L156) Any insights would be highly appreciated. I did not find much about this behavior in the actual documentation. ---
**Author:** ![nilmerg](https://community.icinga.com/user_avatar/community.icinga.com/nilmerg/32/277_2.png) [@nilmerg](https://community.icinga.com/u/nilmerg)\ **Post date:** [June 5, 2025, 7:10am UTC](https://community.icinga.com/t/icingadb-web-protected-vars-behavior/14904/2 "2025-06-05T07:10:20Z")
It’s expected. 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](https://icinga.com/docs/icinga-web/latest/doc/06-Security/#privileges) To achieve what you want, you need to define the protections in a single role. A base role for example. ---
**Author:** ![w1ll-i-code](https://community.icinga.com/user_avatar/community.icinga.com/w1ll-i-code/32/8526_2.png) [@w1ll-i-code](https://community.icinga.com/u/w1ll-i-code)\ **Post date:** [June 5, 2025, 12:16pm UTC](https://community.icinga.com/t/icingadb-web-protected-vars-behavior/14904/3 "2025-06-05T12:16:59Z")
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… ---
**Author:** ![nilmerg](https://community.icinga.com/user_avatar/community.icinga.com/nilmerg/32/277_2.png) [@nilmerg](https://community.icinga.com/u/nilmerg)\ **Post date:** [June 5, 2025, 12:46pm UTC](https://community.icinga.com/t/icingadb-web-protected-vars-behavior/14904/4 "2025-06-05T12:46:08Z")
> Are there any plans to bring back the Security tab? No. The sole intention of making the protections a restriction was to make it possible to configure it dependent on role memberships. > I want a feature to assure that what you see is actually what you get That’s what the Audit view is for. And careful consideration who can when edit authorization configuration 😉