Andreas Ericson wrote:
> Matthias Flacke wrote:
> >=20
> > The question is how to ensure that the plugin output which Nagios recei=
ves
> is=20
> > really the same the plugin sent. There are multiple causes in between
> which=20
> > might change it: cutting off due to small buffers, or misconfiguration,=
=20
> > filtering, escaping, quoting issues...
> >=20
>=20
> 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 character=
s,
> 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.
>=20
> There is also database logging modules. They ofcourse have to make sure n=
o
> 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 h=
as to take care of any oddities.=20
> > A solution could be that the plugin provides a CRC for its output which=
is
>=20
> > checked afterwards. This could be included in the sanitized_output
> option.
> >=20
>=20
> 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:=20
A plugin uses both return code and output (let's assume 10K), but during NR=
PE transport only the first 4K survive due to NRPE and kernel compile limit=
ation. The return code is OK but the plugin output is shortened silently an=
d 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 =3D buffer + 1...=20
> > Generally I would say that it's Nagios part to validate the sanity of t=
he
>=20
> > transport and raise UNKNOWN if not ok.
> >=20
>=20
> 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 wher=
e I can do everything easily (maybe such a CRC or something else). On the r=
eceiver 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
--=20
http://my-plugin.de/check_multi
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]