On Thu, Jul 13, 2006 at 11:16:12AM -0400, Aiello, Steve (GE, Corporate, consultant) wrote:
(http://www.hswn.dk/hobbiton/2005/05/msg00369.html). That solution really only limits users from viewing different pages. The maint option under the device info report is located under the /hobbit-cgi/ and I do not see a way to limit users from disabling devices they shouldn't.
It's not entirely correct that the "maint" option on the info page is freely accessible. Even though there's a link to disable tests directly on the info page, doing so still goes through the normal maintenance script in the secured hobbit-seccgi area, so a login is required to use that function. But as you point out:
If a user has an admin password, they seem to have admin rights to all of hobbit.
That's true. Hobbit in itself doesn't implement any security mechanisms. Neither does BB, by the way. Your modifications to maint.pl were needed to implement this.
What I do at work is to require logging in just to view stuff. No anonymous access allowed; and then I control access to the webpages so users can only see the pages with the hosts they are allowed to touch. This does keep users from doing something by accident, but it will not prevent a determined attacker from getting access to view information about hosts if he knows the hostname (you can manually enter the URL's for e.g. the hostsvc CGI to get at the information you want). And if he has an admin password, then yes - he can disable anything he likes.
Under Hobbit I do not see anyway to define HostGroups, so my old method will not work. Using HostGroupings seemed ideal in that it linked alerts being sent to users and the user's ability to disable devices/tests.
It only solves part of the problem, really. In most cases where my users need to disable something, it isn't because of an alert - it's because of planned maintenance. I personally don't think systems should be disabled because something breaks; the alert should be acknowledged, not disabled. But I guess there are different ways of using the system.
I don't have a ready solution to this. Solving this "the right way" would require implementing a true user authorization system inside Hobbit; some way that you could assign access right to various parts of the system based on the identity of the user. That's a pretty big chunk of stuff to put into the Hobbit UI - but I'm pretty sure it will become necessary at some point. Certainly if Hobbit drops all of the statically generated webpages that you can control access to via your webserver access controls; dropping the static pages would be nice because you would eliminate the overhead of generating webpages that are not used, and what you see will always be up-to-date. So it's something that I have considered doing, and when it happens - then we'll need to implement authorization and access controls in Hobbit.
In the mean time, it would be possible to hack something together like what you've done with maint.pl. When a user tries to disable/enable a test, the hobbit-enadis.cgi tool could look up the list of alert-recipients for this particular host+test combination, much like hobbitd_alert does when you use the --test option. It's a reasonably simple call to one of the Hobbit library routines. If the user is not on the list, then deny his attempt at disabling the test.
Regards, Henrik