GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
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
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.
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.
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.
Updated by jmosshammer on 2011-04-14 07:14:45 +00:00
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.