another question

[Joe Pruett]

> Yes, the difference is that files created by the webserver aren't group
> nagioscmd and the webserver doesn't default to the nagioscmd group which
> has implications beyond nagios if you're running other web apps on the
> same machine.

anything running under the web server will have the permissions of 
nagioscmd.  so any php, ssi, cgi will have those perms and be able to 
write to the nagios.cmd pipe.  my setup will allow any web process to 
invoke cmd.cgi which seems like a lesser exposure.

> I don't know what you believe the issue to be with the current
> authentication system but IMHO, it's very simple and flexible as is and
> works across a wide range of webservers with no special requirements
> other than .htaccess support. .htaccess supports a wide range of
> authentication mechanisms allowing for the administrator to choose the
> auth mechanism that suits their environment best (PAM, LDAP, etc). Any
> coded auth system is going to be much more limited.

if nagios had its own auth mechanism, then cmd.cgi could verify that info
and thereby eliminate the ability for random people to submit commands to
nagios via any of the methods i mention above.  this all assumes a server
that runs other applications.  if you have a dedicated nagios box, then
things aren't as complicated.  also if you had a builtin auth mechanism,
you could timeout sessions, control which functions various people can do
(now that is just done by matching the web username to the nagios contact
name), and eventually you'd be able to easily add/change/remove access via 
the web interface.  i assume that long term nagios will have the ability 
to add/change/remove objects via the web as well so all of this would tie 
nicely together.



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt