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
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Reply via email to