In message ,
[email protected] writes:
>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
>> of course 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, eve n if it's only half of the
>stuff.
>
>How can I deal with this problem?
You are concerned about truncation and not corruption
(if you have corruption I imagine you will get all
sorts of strange characters, and you have bigger
issues).
One thing that comes to mind is an end of data (EOD)
marker . However checking for it should bepa
optional and on a per service basis. So older plugins
that don't support/need the EOD marker can still
function.
The EOD is simple to add and doesn't have the overhead
of checksums which are overkill for this.
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]