John P. Rouillard wrote:
> In message ,
> Ton Voon writes:
>
>> I'm trying to wrap up this RFC from October last year (http://
>> thread.gmane.org/gmane.network.nagios.plugins.devel/4199) so that we
>> can have some text written in the developer-guidelines before
>> starting work on implementing it.
>>
>> This is a summary of the thread on it. I think I have all the angles
>> covered, but please let me know if not.
>>
>>
>> PROBLEM
>>
>> There are security issues with passing user authentication
>> information into some plugins via the command line. We would like the
>> use of configuration files, secured at the file level, allowing
>> configuration variables on a per-plugin basis.
>>
>> PROPOSED SOLUTION
>>
>> A new option is allowed: --extra-opts. The idea is this option is
>> "replaced" with configuration options within a configuration file.
>
> Well, one thing that was discussed on the nagios list for nagios 3 was
> the ability to use host object specific macros
> (e.g. _snmp_community=private) to keep this data associated with the
> host as different hosts may have different info. My idea was to flag
> some of these macros to be sent on stdin and not passed in the
> environment. So the plugin would get:
>
> _snmp--community=private
> _snmp--username=fred
>
> on standard in to set '--community=private' and '--username=fred'.
>
> Could the RFC be extended to allow:
>
> --extra_opts=-
>
> that will read on stdin lines of the form above and parse them using
> the last -- seperated segment as the option name.
>
> It seems that there is a 1:1 correspondance between arguments to a
> plugin and the host object macro so that each macro would be used for
> only one plugin invocation. If there was a case where the same
> username had to be passed as various parameters: --name, --username,
> --account etc for different plugins then a small shell filter could be
> used:
>
> define host {
> name foo
> _admin-login-account nagios
> ...
> }
>
> define command {
> command_line filter mysql | check_mysql --extra-opts=- ....
> ...
> command_input _admin-login-account
> }
>
> define command {
> command_line filter snmp | check_snmp -v 3 --extra-opts=- ....
> ...
> command_input _admin-login-account
> }
>
>
> where "filter" is responsible for changing an input value of:
>
> _admin-login-account=nagios
>
> to '--username=nagios' when given the "mysql" argument,
> '--secname=nagios' when given the argument snmp etc. (or we may be
> able to define some mapping mechanism that can be done by nagios
> without the need for the filter:
> e.g. secname=$_admin-login-account(default)$ would produce
> secname=nagios if _admin-login-account is defined for the host or
> secname=default if the mcro is undefined.)
>
> Being able to inherit this info from nagios means that managemnt
> interfaces developed for nagios can display (and change) this info
> without having to develop an add on mechanism. The data is kept with
> the host allowing nice printouts of the data and automatic generation
> from higher level management tools (e.g. inventory databases).
>
> Granted using --extra-opts=$HOSTNAME$ also allows for per host
> definitions files, but being able to use the nagios provided
> capability when they are available would also be a big win.
>
> -- rouilj
> John Rouillard
I prefer using the proposed config file solution to store passwords,
etc. over the idea of passing this info via stdin. In my opinion, the
config file option is a much simpler/elegant solution.
It requires no mods to the Nagios daemon or plugin API. Super-secret
info can be stored in the config file and locked down with standard file
permissions. And a standard library/function set can be created to
allow Perl/C plugins to grab their appropriate entries out of the config
file.
Now that I'm thinking about it, this type of file format seems like it
must be used by a number of apps. There's probably a GPL'ed library out
there that can read/write con
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]