[hobbit] Multiple User Admin mode

[Henrik Stoerner]

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