Rethink permission subsystem
|Icinga Version:||DB Type:|
|Icinga Web Version:||DB Version:|
|IDO Version:||Browser Version:|
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.
#3 Updated by jmosshammer about 4 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.