[Nagiosplug-devel] [RFC] Plugins config file

[Gavin Carr]

Hi Sean,

On Mon, Oct 16, 2006 at 07:06:11PM +0200, sean finney wrote:
> On Mon, 2006-10-16 at 21:13 +1000, Gavin Carr wrote:
> > 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.
> 
> i've brought this up before, actually (though at the time it was
> regardling snmp auth info, but same problem)
> 
> > 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?
> 
> well, for the db plugin, assuming that it's a mysql program, why not
> use the built-in functionality for  reading in additional mysql
> ini-format files?  it should be possible to say something like
> 
> check_db_plugin --defaults-file=/etc/mysql/nagiosplugin.cnf
> 
> where you use getopt to get the defaults-file value, and pass it to the
> mysql "load_defaults" function with the proper parameters.

Because:

- it's database specific - not every database supports these kinds of 
  defaults, and those that do support it in quite different ways

- it's client specific - the above works for the 'mysql' client, but does
  it work for the php/perl/python/ruby bindings? 

- it's a more general problem anyway than just databases, as you're snmp
  auth info example above illustrates

> > 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.
> 
> i would be rather wary of this, because it's yet another point of
> configuration/abstraction in an already complicated system.  but that's
> just mho.

I'm wary of the additional complexity too. But I do think we need _some_
mechanism like this for parameters we don't want to pass on the command 
line, and I can't think of anything simpler that is reasonably general and
useful. What did you end up doing in your snmp auth info case?

At least two things are evident in the discussion so far:

- other people have run across the same problem, and have rolled their own
  solutions

- it's easy for even highly technical people to come up with solutions that
  have security holes in them

I think these two together argue that this would be useful infrastructure 
we could supply to plugin authors.

Cheers,
Gavin