Bug #986

Rethink permission subsystem

Added by tgelf over 3 years ago. Updated about 3 years ago.

Status:ClosedStart date:11/09/2010
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Icinga Version: DB Type:
Icinga Web Version: DB Version:
IDO Version: Browser Version:
OS Version:

Description

Currently permissions are enforced by filters in different places. A recent issue (already fixed) not only showed all "Open Problems" even if you where not allowed to see them: a click on that page on a "foreign" host has been possible and succeeded. While the former is no longer true, someone playing around with Firebug or similar tools will probably easily be able to reproduce the latter.

The latter is IMO critical, it should be addressed immediately. As a long-term solution I'd suggest to move permission checks to another layer. This may be the API, the database backend or even another new abstraction layer. The current design is weak, new security issues can easily be introduced with potentially every modification, new module or cronk.

Please not that I'm just guessing blindly, I didn't do any farther tests or research to prove that my statements are correct.

History

#1 Updated by jmosshammer over 3 years ago

Permissions are done in the api and directly affect the sql queries.
You shouldn't be able to request what you aren't allowed to see, but i will check this.

#2 Updated by ralfk over 3 years ago

First I would like to know how permissions are configured. And how they affect the filters and cronks. It's still unclear to me.

#3 Updated by jmosshammer about 3 years ago

  • Status changed from New to Closed

The permission system is simple (but effective):
At this time, if you have a user with 'hostgroup' = 'Myhostgroup' as limitation, the Api always limits the sql queries via the where clause.
The permission subsystem will be rewritten when the new api is finished, should be 1.5.

Also available in: Atom PDF