group_authorization == loose gives permission to all groups

In strict group authorization (AND operator between all host authorizations
tests) bails out with a return false if ANY host isn't authorized. This is
correct.

In loose group authorization (OR operator between all host authrozations tests)
bails out with a return true if ANY host is authorized. This is also correct.

But having a default return true at the end if not bailed out seems to be a
good idea if returning false in all other cases before. This is ok for strict
autorization.

But default returning true, if all other cases has returned... well... true
before might be an interesting case, that well... never could have worked... If
not returned true before, return true now.

Signed-off-by: Max Sikström <msikstrom@op5.com>
authorization: Change handling of empty groups

Before, a user was always authorized for a group if the group had no
members - and, after the parent commit, we also had to be in strict
mode for this to be a problem.

It's a tricky case - we're not authorized for the group, but we're also
not /not/ authorized. However, my motivation is two-fold:

A customer let us know that they were unhappy with the current behavior,
and could motivate the unhappiness properly: when you're preparing
configuration for new limited users, you don't want your old, unrelated
limited users to see the new (partial) configuration.

Additionally, it intuitively makes sense that the "strict" mode only
lets you see groups where you're contact for at least one member - the
old behaviour was that it only let you see groups where you're not
unauthorized for anything.

Signed-off-by: Robin Sonefors <robin.sonefors@op5.com>
Table hosts/service: Expose check_source

To be able to determine the source of the check, the check_source parameter is
needed to be available to the frontend. That contains either which worker
runned the check, or which merlin node.

Signed-off-by: Max Sikström <msikstrom@op5.com>
Filter out custom_variables that shouldn't be exporeted using prefix

To be able to use custom variables to store certain configuration parameters to
services and host checks, such as service account information, those variables
needs not to be exported to any GUI, but just be kept inside of nagios.

That means, those variables needs to be masked in the inteface between nagios
and the GUI, which for most cases is livestatus.

This patch adds the configuration line hidden_custom_var_prefix=PREFIX to the
broker_module line in nagios.cfg, which makes all custom variables with that
particular prefix hidden in the livestatus interface.

Should resolve a big part of #7894

Signed-off-by: Max Sikström <msikstrom@op5.com>
spec: Put op5's reserved hidden_custom_var_prefix in place on upgrades

I'll need to test this further on monday.

Signed-off-by: Robin Sonefors <robin.sonefors@op5.com>