[dev.icinga.com #986] Rethink permission subsystem

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/986

Created by tgelf on 2010-11-09 20:55:50 +00:00

Assignee: (none)
Status: Closed (closed on 2011-04-14 07:14:45 +00:00)
Target Version: (none)
Last Update: 2011-04-14 07:14:45 +00:00 (in Redmine)

---

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.

[icinga-migration]

Updated by jmosshammer on 2010-11-12 19:07:01 +00:00

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.

[icinga-migration]

Updated by ralfk on 2010-11-19 08:30:15 +00:00

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

[icinga-migration]

Updated by jmosshammer on 2011-04-14 07:14:45 +00:00

• 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.