[icinga-users] Object filter problem with hostgroups/contacts in Icinga Web 2

Peter Eckel lists at eckel-edv.de
Tue Nov 14 15:01:06 CET 2017


Hi, 

I ran into an annoying problem with object filters in Icinga Web 2/Icinga 2. 

Versions are Icinga 2.7.1 and Icinga Web 2.4.2, but it does not seem to be limited to these versions. 

I defined some host groups and a couple of Icinga Web 2 users, giving groups of users access to groups of hosts using monitoring/filter/objects. This works fine. 

What also works as expected is that when a user has access to a host, he or she also has access to the services on that host, as there are no service group filters defined at the moment. This works fine as well, just as I'd expect.

Now starts the tricky part: When there are notifications assigned to a host object, a user with access to that host object is able to see the contact (either via Overwiew/Contacts or by clicking on the contact's display name in the host object's page) and, for instance, the history of notifications sent to that contact. Again, that is what I would expect, so everything is OK. 

But here's where the trouble starts: The same logic does *not* apply to contacts that are only used for services, not for hosts the user can access. The rationale behind that is that there are a couple of teams (with associated contacts/contact groups) responsible for the servers, but different teams are responsible for the applications and the latter are not notified of host outages, so their associated contacts are only used for service notifications. 

When clicking on a contact name that is associated with a service and not a host, the following (extremely unhelpful and massively abridged) error message is displayed in the Web GUI:

> Trying to get property of a non-object
> 

> #0 zend.view:///usr/share/icingaweb2/modules/monitoring/application/views/scripts/show/contact.phtml(8): Icinga\Application\ApplicationBootstrap->Icinga\Application\{closure}(8, 'Trying to get p...', 'zend.view:///us...', 8, Array)
> #1 /usr/share/php/Icinga/Web/View.php(231): include('zend.view:///us...')
> #2 /usr/share/icingaweb2/library/vendor/Zend/View/Abstract.php(877): Icinga\Web\View->_run('/usr/share/icin...')
> #3 /usr/share/icingaweb2/library/vendor/Zend/Controller/Action/Helper/ViewRenderer.php(904): Zend_View_Abstract->render('show/contact.ph...')
> #4 /usr/share/icingaweb2/library/vendor/Zend/Controller/Action/Helper/ViewRenderer.php(925): Zend_Controller_Action_Helper_ViewRenderer->renderScript('show/contact.ph...', NULL)
> #5 /usr/share/icingaweb2/library/vendor/Zend/Controller/Action/Helper/ViewRenderer.php(964): Zend_Controller_Action_Helper_ViewRenderer->render()
> #6 /usr/share/icingaweb2/library/vendor/Zend/Controller/Action/HelperBroker.php(272): Zend_Controller_Action_Helper_ViewRenderer->postDispatch()
> #7 /usr/share/icingaweb2/library/vendor/Zend/Controller/Action.php(518): Zend_Controller_Action_HelperBroker->notifyPostDispatch()
> #8 /usr/share/php/Icinga/Web/Controller/Dispatcher.php(76): Zend_Controller_Action->dispatch('contactAction')
> #9 /usr/share/icingaweb2/library/vendor/Zend/Controller/Front.php(937): Icinga\Web\Controller\Dispatcher->dispatch(Object(Icinga\Web\Request), Object(Icinga\Web\Response))
> #10 /usr/share/php/Icinga/Application/Web.php(389): Zend_Controller_Front->dispatch(Object(Icinga\Web\Request), Object(Icinga\Web\Response))
> #11 /usr/share/php/Icinga/Application/webrouter.php(109): Icinga\Application\Web->dispatch()
> #12 /usr/share/icingaweb2/public/index.php(4): require_once('/usr/share/php/...')
> #13 {main}

The contact is not shown in Overview/Contacts either. The notification history can, however, be accessed via 'Overview/Notifications'. 

The problem disappears when the user is either explicitly given access to the service in question using a filter object (which is not a feasible solution in  general because the filter list would become HUGE), or when the filter objects restricting the access to hosts are removed. So it seems that the root cause is the lack of transitivity of permissions beyond service objects: 

User A is permitted to see Host X via filter object:

-> Host X is accessible
-> Contact M with a notification for host X is accessible
-> Service Y on host X is accessible
-> Contact N with a notification for service Y on host X is *not* accessible

Seems like access rights are inherited over one level, but not over two.

Did anyone run into this before? Any easy solution, or should I open an issue for it? If anything is unclear, I'll be at OSMC next week and will be glad to discuss it further. 

Best regards, 

  Peter.


More information about the icinga-users mailing list