[Nagiosplug-devel] [RFC] Plugins config file

Ton Voon ton.voon at altinity.com
Mon Oct 16 15:46:09 CEST 2006


On 16 Oct 2006, at 12:13, Gavin Carr wrote:

> I've got a perl nagios plugin that performs arbitrary queries against
> a database and reports status codes based on the number of rows
> returned i.e.
>
>   Usage: check_db_query_rowcount [-v] -q <query> -w <warn-count>
>             -c <crit-count> -d <dsn> -u <user> -p <pass>
>
> An obvious security problem with this is that the user must pass the
> database credentials on the command line, which typically means
> they're exposed to any local users via the process list for however
> long the plugin executes.
>
> This must be a problem for lots of other kinds of plugin too -
> anywhere you need to pass any kind of secret to a plugin. Is there a
> good way of dealing with this that I'm not aware of?

If you run mysql (I'm on 4.1.11) with -u user -ppassword, the process  
table will have the password blanked out. I've done that in C (see  
check_mysql_query), but I don't know how to do that in perl. Would  
that be sufficient?

> My suggestion is that we introduce a config file specifically for use
> by plugins (e.g. /etc/nagios/plugins.cfg or
> $NAGIOS_HOME/etc/plugins.cfg), for arbitrary per-plugin parameters we
> don't want to have to pass at the command line. Perhaps an INI-style
> format would make sense, with per-plugin sections, or arbitrary
> section names specified explicitly e.g.
>
>   [ check_db_query_rowcount ]
>   dsn = db:Pg:database=foo
>   user = fred
>   pass = secret
>
> or perhaps if I want to check multiple different databases, or share
> the credentials across plugins:
>
>   [ foo_db ]
>   dsn = db:Pg:database=foo
>   user = fred
>   pass = secret
>
> Then my plugin could have a usage pattern like this:
>
>   Usage: check_db_query_rowcount [-v] -q <query> -w <warn-count>
>             -c <crit-count> [--auth=<auth-section>]
>
> where auth-section might default to the plugin name if not specified
> (and the plugin would fail if an appropriate auth section could not
> be found).
>
> Thoughts/comments?

A design principle I've been following, although it is undocumented  
and I'm all for starting a discussion about it again, is that plugins  
should run without any knowledge of state (I think the check_log  
plugin might break this - I haven't worked closely on that one). A  
config file for passwords doesn't sound necessary.

However, I guess this is no different from mysql having a my.cnf  
file, so I don't think security gets any worse. My angle is that the  
userid/password used should only have just enough access to do the  
necessary check and no more. That would be an application issue, not  
a plugin one.

Ton

http://www.altinity.com
T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20061016/1a644fd1/attachment.html>


More information about the Devel mailing list