Fixed an error in authentication of *by*group causing sigsegv

Signed-off-by: Max Sikström <msikstrom@op5.com>
spec: Error out less

This should be equivalent to f08bc7c in the old livestatus repository.

Signed-off-by: Robin Sonefors <robin.sonefors@op5.com>
spec: Explicitly versioned python only applies to cent5

Not suse.

Signed-off-by: Robin Sonefors <robin.sonefors@op5.com>
spec: ...and now make rhel-derivs work again

We need *both*?

Signed-off-by: Robin Sonefors <robin.sonefors@op5.com>
spec/autoconf: resolve FIXME, be explicit about ac prereqs

This is neater than sed'ing the configure.ac. Besides, I doubt we're
using any fancy features that were introduced in the two microreleases
that our buildsystems is lagging from the original.

Signed-off-by: Anton Lofgren <alofgren@op5.com>
module: fix memory leaks, free() args in argument parser

Not sure what the removed comment is supposed to convey (diff for
details).

Signed-off-by: Anton Lofgren <alofgren@op5.com>
Update README to describe Sort:/Offset:/wrapped_json

Signed-off-by: Max Sikström <msikstrom@op5.com>
README: Spelling error

Signed-off-by: Max Sikström <msikstrom@op5.com>
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>