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.
_______________________________________________
icinga-users mailing list
[email protected]
https://lists.icinga.org/mailman/listinfo/icinga-users