[Nagiosplug-devel] Re: check_by_ssh patch

[Paul L. Allen]

I really shouldn't feed the trolls, but there's a slight possibility
he's serious but misguided. 

Andreas Ericsson writes: 

> Paul L. Allen wrote:
>> Andreas Ericsson writes:
>>> and that it is a fair amount slower (even with the epn) than a properly 
>>> written C-program.
>> 
>> It depends very much on what you're doing with it.  For number-crunching
>> it is slower, for uses where it runs, does a few things, then terminates
>> then the difference can be a lot smaller. 
>> 
> Datacrunching in general. check_ifoperstatus runs in 6 seconds real time 
> whereas a shellscript checking multiple interfaces at the same time runs 
> in 1 second.

Somebody else already answered you on that one.  He doesn't see the
results you're seeing.  His results are a lot faster than yours. 

>> Anddefining a programming language as "industrial strength" first 
>> requires you to state whether you are basing your definition on 
>> programmer efficiency, CPU efficiency, memory efficiency or other 
>> criteria.
> 
> Language possibilities. If you can't do it in C, it can't be done at all.

The same is true of any Turing-complete language with full access to
operating system calls, *or* a way of getting to them.  With perl, a
*small* number of syscalls on *some* platforms are not accessible from
the language itself but *can* be accessed via modules.  Hint: perl on
Risc OS can access all syscalls. 

>> Perl has a lot of stuff that C lacks without adding libraries that are 
>> not a standard part of C.
> 
> But not without perl modules.

Really?  Regexes are a standard part of the perl language, no modules
required.  If you want regexes in C you have to hunt out non-standard
(as in not supplied with C compilers and not part of the ANSI standard)
libraries.  The same goes for many perl features. 

>> Useful stuff like data structures, regexes and
>> memory management.
> 
> Ofcourse it has memory management. Every script language in the world does 
> memory management, and virtually every script language has data 
> structures.

Yes, C has memory management.  If you remember to call malloc and friends
carefully and don't make any mistakes.  Perl takes care of it for you.
C has fairly primitive data structures, but if you grab non-standard
libraries or write your own code you can have the equivalent of perl's
arrays and hashes.  Etc. 

>> Stuff that allows perl programmers to be more
>> productive and means they don't have to take care to avoid buffer
>> overflows.
> 
> There's always a tradeoff in development time if execution time is more 
> important. This is true in perl as well.

Yes, it is.  I wouldn't write an operating system in perl, and I wouldn't
write a plugin in C.  Horses for courses.  If you really need execution-
time speed, you can generate C code from perl.  Not as fast as hand-written
C, but an improvement. 

>>> This means that some things just can't be done without C-coding anyways.
>> 
>> Most things can be done in perl without C coding, although a small number
>> of them would be a little inefficient.
> 
> A gross overstatement followed by an equally gross understatement.

Crap.  Perl will let you do anything any Turing-complete language will
let you do, provided you do not need to access every possible syscall.
Most *useful* syscalls already have perl equivalents or are accessible
from perl's syscall function.  Sure, a perl module written in C that
computes MD5 hashes would be more efficient than a native perl
implementation because there is some serious ALU-bashing, but you can
*do* it in pure perl if you want. 

>> Most, but not all, syscalls can be
>> handled by perl.  For the few that cannot you need an XS module to 
>> provide
>> the glue.  Since perl is Turing-complete, with a little XS to take care
>> of the small number of syscalls that return multiple values and which
>> are not already accessible natively, it can do anything you can do in C. 
>> 
> So what you're saying is;
> Code it in C, then write some more code so that the third layer of code 
> you write (the perl script) can access the code you wrote first.

So what I'm saying is that for most cases you don't need C.  Take a
look at the perl plugins.  NONE of them make use of C-code modules that
I know of.  In the few cases you need a module to access a syscall,
somebody has already written it for you.  We can say the same thing
about any non-standard C libraries you use that were written by others. 

> How does this make development time faster and more efficient?

Most competent programmers understand that programmers generate the
same average number of *fully* debugged lines of code a day no matter
which language they write in.  It is left as an exercise for the reader
to compute the average code-density ratio of perl and C. 

> Those same functions can be called and linked from any C program 
> without the intermittent layer and the top-level code.

You can do anything from any language, if you try hard enough. 

>>> If we set all that aside there is still the issue of having every bug 
>>> ever intoduced in Perl spread to every plugin written in it
>> 
>> As opposed to every bug ever introduced into the C compiler and 
>> libraries,
> 
> ... which ALSO fan down into Perl.

ROFL.  I wondered if you'd fall for that one.  I didn't think you were
that foolish, but you were.  Do you know how much of the perl installation
process is devoted to detecting known bugs in operating systems and
compilers and finding the secure alternatives?  Perl tries hard to avoid
hitting on known bugs in OSs and compilers.  Perl also does not use every
feature in C that a C programmer might use. 

>> along with every bug introduced by plugin authors being careless with
>> buffer overflows and who use printf without a format specification.
> 
> A plugin is not a big thing to audit. Fix the bugs and you're back in the 
> fast lane again.

A plugin is a gigantic thing to audit if you check everything it calls.
I remember mentioning to you just how much of the TCP stack is in kernel
space these days but I haven't seen a response. 

However, as Karl pointed out, the important issue is that plugins get
written.  More people are happy writing them in perl than in C.  If
you were to put your money where your mouth is and convert all the
perl plugins to C then I think they would be accepted.  Most of us
would prefer a perl plugin that does X than no plugin at all because
you insist all plugins be written in C and the people who are confident
with C have no interest in X.  Some of us live in the real world where
things have to get done... 

>>> (currently mostly temporary filehandling stuff).
>> 
>> For which there are three solutions.  One of which is not recommended
>> because it relies upon C's tmpfile(3) implementation - which is broken
>> on some systems. 
>> 
> And should be fixed to be secure and honor the $TMPDIR environment 
> variable.

Perl knows there are problems with some implementations of tmpfile(3).
Perl documentation points out the problems.  Many C programmers have
no idea their vendor ships a broken tmpfile(3).  Even if your OS does
it right, other people's OSs may not.  I'd prefer a solution that works
everywhere, not a solution that works only on the OSs I happen to run. 

A *good* coder works around the limitations of many platforms rather
than coding purely for his own platform.  Perl simplifies that process
by already knowing about many of those problems. 

>> Anyone who was in a position to know what they were talking about when
>> commenting on the deficiencies of perl would know that Nagios does not
>> have to run as root to run a setuid script.
> 
> I know that, but how does it work under the hood? If perl (the program) is 
> invoked every time a precompiled image needs to execute I seriously doubt 
> the effectiveness of the epn. If it doesn't, then how can it the elevated 
> privileges of the script be retained?
> That's why the epn was mentioned in the follow-up question.

Now that's a good question, and one I don't have the answer to since
I haven't looked at epn (too unstable for my liking).  Embedded perls
are usually C programs that call the perl functions needed.  I don't
see any reason, in principle, why setuid scripts could not be handled
by epn, but it would probably get messy with separate instances being
forked, and piped communications, and might require some rewriting of the
plugin.  In practise, the only plugin I have seen that needs to run
an external command as another user called sudo. 

I expect that is possible to conceive of problems that cannot be
handled that way.  But they can all be worked around.  Apache's suexec
will *not* run setuid scripts, but I once (reluctantly) wrote a couple
of perl scripts that ran under suexec and defeated its checking.  It's
not rocket science to get around these problems, just a matter of
judgement as to whether or not that is the best solution.  I warn people
who ask for this sort of stuff that they're opening serious security holes
and that I strongly advise against it - but if they then insist they want
to pay me to do it then that is their concern. 

> On a personal note;
> I really don't like your tone. You dismiss without knowing, you are 
> arrogant when you should be humble and you are stubborn enough to teach
> a mule.

You're projecting your own faults onto others. 

-- 
Paul Allen
Softflare Support