[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