nagios2 plugin output sanitization

[Matthias.Flacke at gmx.de]

Andreas Ericson wrote:
> Matthias Flacke wrote:
> > 
> > The question is how to ensure that the plugin output which Nagios receives
> is 
> > really the same the plugin sent. There are multiple causes in between
> which 
> > might change it: cutting off due to small buffers, or misconfiguration, 
> > filtering, escaping, quoting issues...
> > 
> 
> Nagios should (and does) do a byte-by-byte copy of whatever the plugin
> returns.
> Stripping malicious output is an exercise left to the medium where it's
> used. After all, plugin output could just as well contain shell characters,
> and
> Nagios dabbles in that area too (when sending notifications, notably).
> Escaping
> html output in the core will btw add many such shell control chars.
> 
> There is also database logging modules. They ofcourse have to make sure no
> sql
> injection attempt slips past.

You're right concerning the content itself. The plugin can send whatever it likes to and the frontend or DB or whatever works with the plugin output has to take care of any oddities. 

> > A solution could be that the plugin provides a CRC for its output which is
> 
> > checked afterwards. This could be included in the sanitized_output
> option.
> > 
> 
> This is a big nono. A very large part of Nagios' success is that it's
> really,
> really easy to add functionality to it by providing a plugin that does
> something, prints something and then exits with one of four well-defined
> exit codes.

I understand your point and surely don't want to break the simplicity. But take the following scenario: 

A plugin uses both return code and output (let's assume 10K), but during NRPE transport only the first 4K survive due to NRPE and kernel compile limitation. The return code is OK but the plugin output is shortened silently and nobody notices this... I don't think that NSCA handles this differently.
I don't want to 'solve' the problem increasing the buffers, since tomorrow certainly a message comes around with length = buffer + 1... 

> > Generally I would say that it's Nagios part to validate the sanity of the
> 
> > transport and raise UNKNOWN if not ok.
> > 
> 
> You're wrong. Nagios needs to validate (and fix) the strings it uses
> depending
> on the context where it's used. The output from the plugins is written to a
> file as far as Nagios core is concerned, so there's really no need to
> mangle
> them at all.

I meant the transport level only. On the sender side there is a plugin where I can do everything easily (maybe such a CRC or something else). On the receiver side there is Nagios core where any bytes are gracefully received, even if it's only half of the stuff. ;-)

How can I deal with this problem?

-Matthias

-- 
http://my-plugin.de/check_multi


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/