[Nagiosplug-devel] check_ping and check_icmp confusion

[Jason Crawford]

On 2/22/06, Andreas Ericsson <ae at op5.se> wrote:
> Andreas Ericsson wrote:
> > Jason Crawford wrote:
> >
> >> On 2/22/06, gh <gh at 3gupload.com> wrote:
> >>
> >>> On Wed, 2006-02-22 at 18:36 +0100, Andreas Ericsson wrote:
> >>>
> >>>> gh wrote:
> >>>>
> >>>>> From what I can tell check_ping has been deprecated in favor of
> >>>>
> >>>>
> >>>>> check_icmp. Is this the case or are there certain systems or
> >>>>> conditions
> >>>>> that make check_ping favorable or even necessary?
> >>>>>
> >>>>
> >>>> check_icmp had some problems on systems with 32-bit process id's in the
> >>>> early days (causing it to mark the packets wrong and then not
> >>>> recognizing them when they returned). It also used to calculate timings
> >>>> slightly wrong. Both those problems are solved long since, however. Now
> >>>> there are no real reasons to use check_ping instead of check_icmp.
> >>>>
> >>>
> >>> What do people think about just dropping check_ping from the next
> >>> version of the plugins package to avoid all this unnecessary confusion
> >>> that is evident on the mailing lists and replace it with a symlink to
> >>> check_icmp for backwards compatibility?
> >>>
> >>
> >>
> >> I just don't like the fact that check_icmp must be setuid root or run
> >> as root. Personally, I like to have as few setuid binaries as possible
> >> on my system, as well as little running as root as possible
> >
> >
> > This is both sane and wise.
> >
> >> (in order
> >> to run check_icmp as root, the parent nagios stuff must be running as
> >> root as well).
> >
> >
> >
> > This is a downright lie. setuid binaries are executed with the
> > permissions of the owner of the file. Nagios does *not* have to run as
> > root (otherwise check_ping would fail as well).
> >
> >
> >> The great thing about check_ping is that it uses the
> >> already setuid ping binary.
> >>
> >
>
> Oh, and the most compelling reasons not to use check_ping:
> * It runs /bin/ping and parses the output. This works nicely so long as
> the developers have access to a ping that produces output in a certain
> format, but that's not as predictable as some like to think.
> * It is *much* slower than check_icmp.
> * It consumes more resources.
> * The code is ugly enough to make a mans eyes pop.
>
True, trying to use /bin/ping on a system no developer has seen yet
would be a bit difficult, as well as running a separate binary does
take up more resources. And when I was trying to track down that
check_ping segfault issue, going over that code wasn't the easiest.
Having check_icmp chroot(2) itself would definetly improve security
quite a bit, but I also wonder how much more resources it would
consume (never did chroot(2) benchmarks before).