[Nagiosplug-devel] Re: Embedded Perl (was check_by_ssh something...)

[Paul L. Allen]

Andreas Ericsson writes: 

> Paul L. Allen wrote:

> For functionality, yes.

For functionality all you need is shorts.  You can build everything
up from those.  It's just hard work.  I made this point earlier when
suggestion writing opcodes.  It can be done, but why would you want
to?  Considering how many C programmers overflow fixed buffers
and walk off the end of arrays when they try to build a data structure
of a type offered natively by perl but not by C, richer data structures
with protecion a part of the language can be a distinct advantage.
Especially when you need to write something quickly. 

>> Hashes are not just convenient, they solve many problems that would scale
>> badly and run very slowly without them.
> 
> If the code is written properly, scaling is not a problem. If it isn't, no 
> language in the world will do the trick for you.

Having a language that has hashes as a native data structure takes the
hard work away from you.  Sometimes you can gain a bit of efficiency
by using other methods, but you're trading increased programmer time
for decreased execution time. 

>> Of course, you can write your own hash code, but good hashing code is 
>> difficult to write.  Or you could find a C library.  Or you could use 
>> perl. 
>> 
> Enter simple mathematics. I argue that good hashing code is trivial to 
> write as long as it has been properly implemented from the beginning.

It's trivial to write.  It's somewhat harder to write well.  Perl's
hashing function has changed over the years both to accommodate a
tendency for people to use larger hashes and to adopt a new hashing
algorithm that somebody came up with. 

>>> Bah. Some plugins should be written in C. Those that parse a lot of text 
>>> should be written in perl, and those that rely on external commands for 
>>> their data retrieval (like snmpget and fping) should be written in unix 
>>> shell (it handles program execution better than perl, since it can 
>>> fork() instead of execve()).
>> 
>> And if you rely on external commands that generate a lot of text that you
>> have to parse? 
>> 
> man grep
> man sed
> man awk
> man cut

Ah.  And this comes from the man who says we should write modules in
C because perl is C under the hood.  But when it comes to a task involving
text mangling he advocates a mix of shell (written in C), grep (written
in C), sed (written in C), awk (written in C) and cut (written in C).
They're all C under the hood, so you should write your plugin in C in
the first place. 

>>> The Socket module works with C-code underneath, as does SNMP and File.
>> 
>> The socket module is part of the standard distribution.  Perl is written
>> in C.  Neither of those facts mean that it is sensible to rewrite perl
>> plugins in C just because perl is written in C. 
>> 
> SNMP is not, but I guess you missed that.

It's not part of the standard perl distribution.  That isn't a
justification for your stance of "anything but perl."  The SNMP module
has been written.  The check_if plugin has been written.  They work.  If
I want to do any SNMP checks I'll be using them rather than re-inventing
the wheel.  If somebody writes a C version of the plugin then I'll have
a choice of two wheels.  I suspect the perl wheel will give a smoother,
if slower, ride. 

> Also, if I read Karl's comments on the perl framework correctly, it has 
> almost grown out of its own usefulness.

If I read his comments correctly, perl is the preferred language for
plugins.  The question is whether or not a new framework is going
to be adopted.  The new framework has distinct advantages but the guy
who developed it needs more output for his own use.  I would think
a command-line switch to get more output with the default being current
behaviour would fix that. 

>> With many more lines of code needed to do so, especially if you need
>> text mangling.  I made the point about productivity and your response
>> ignored it. 
>> 
> By reducing the intermittent code layers production times will drop.

Why would that be true if somebody has already written the intermediate
layers?  If you had to write the intermediate layer yourself then
perhaps it would be faster to write in C - it depends on how much hard
work is being done in the plugin, how much code is needed in the
intermediate layer, etc.. 

>>> My point exactly. Why try 'hard enough' to write it in perl if it needs 
>>> C under the hood any way?
>> 
>> Why work hard to code something in many lines of C that could be done in
>> a few lines of perl?  BTW, code generated in C is just a bunch of
>> opcodes and data.  Why write it in C when it's just opcodes under the
>> hood?  Why not write raw machine instructions? 
>> 
> Now you're just being silly.

No, I'm making a point.  You can do anything you want in raw machine
instructions.  Most people would find assembly language more productive.
Most people would find C more productive than assembly.  Most people would
find perl more productive than C.  My boss loves Java but cannot get his
head around regexes, so he knows that when serious text mangling is
involved I can knock up a few lines of perl that would take him many
dozens of lines of Java.  I'd do it in Java using one of the regex
classes available but they don't integrate as closely with the rest
of the language as regexes in perl. 

>> You're doing a good job with the patches.  But, as you admit, you've
>> submitted patches for other things like Apache.  You may have the luxury
>> of not running Apache until you've done a thorough audit and fixed all
>> the holes, most people don't.  The same thing goes for perl. 
>> 
> Are you expecting a reply to this?

I'm pointing out that most people don't have the luxury of refusing to
use stuff that they haven't personally audited to the finest detail.
You may call them stupid, but they don't have the budget you clearly
do, nor the business requirements driving that level of security-
consciousness.  Their business may go down the tubes if they're hacked,
as may yours, but in absolute terms the potential losses and the low
profit margins mean they have to accept the risks.  They're not stupid
because they don't vet code to the degree you do, they're being realistic
about what they can afford to do and hoping that the white hats find
and fix holes before the black hats exploit them. 

> Are you making this up, btw? I live and work in sweden but I've never seen 
> this pension scheme, or any news or anything about it.

Take a look at <URL:
http://perl.oreilly.com/pub/a/oreilly/perl/news/swedishpension_0601.html >. 

>> The point is that most of the stack runs in kernel space and is therefore
>> a potential vulnerability.  Yet another thing to audit. 
>> 
> Do you think I mainly spent my time working on IDE-drivers while auditing 
> the kernel?

I hope not. 

>>> Besides, perl is as vulnerable as anything to kernel bugs.
>> 
>> And C isn't?  Hint: perl is written in C.  So if you can write something
>> in perl that's vulnerable to a kernel bug you can write the same thing in
>> C with the same vulnerability. 
>> 
> 'as vulnerable as anything' wasn't there for rhetorical reasons.

Sorry, I thought you had were using an English idiom.  "Does 'x'
like anything" is a slightly out-of-fashion way of saying something
excels at doing 'x'.  "I put a V8 engine in my volkswagen beetle and
now it goes like anything."  The "like anything" means "like anything
else that is considered to be a top performer" not "like anything else
you can think of because they are all equal." 

>> The same faith I put into linux and apache.  I know that they are going
>> to contain bugs but they are better than the alternatives.  I know that
>> open source development means they are likely to improve.  I know that
>> they may contain bugs, but in the end I need an OS and webserver. 
>> 
> And I'll be happy to provide both. Actually, it's more than just likely 
> that some of the code you rely on was written by me, or based off of work 
> I put into it. Fun, eh?

I can't recall seeing your name as the author or team lead of anything
I rely on, nor in the cast of characters.  But then I rarely look at
the credits. 

>> I don't trust any software to be secure.  Short of disconnecting servers
>> from the internet, there isn't much I can do to be confident I am
>> totally secure.  Unlike you, I don't believe that your patches will
>> make any of these things totally secure because I don't fool myself that
>> I can think of every possible vulnerability or that totally new exploit
>> mechanisms will never be found.
> 
> I don't believe they will make me totally secure. I believe they will make 
> me more secure than I would have been without them.

At last we converge upon agreement.  Now please accept that unlike you,
I don't have the luxury of pulling the plug on stuff I haven't vetted
in great detail, nor do I have the budget to vet stuff to that level.
Nor do most people.  Most big ISPs run Apache.  Some big ISPs contribute
to Apache development.  Even so, you've found holes they missed because
they cannot afford to do the sort of exercise your company can.  Nor
can they simply not deploy Apache until they've vetted it even if they
did have the budget.  I doubt any of them are happy with the risks they
take, but they don't have much option. 

>> Are you advocating setuid as a safer alternative? 
>> 
> No, I suggest the script calling sudo shouldn't be cached. If it is then 
> evey instance of nagios will have an easy shot at a vulnerability in its 
> stack.

I haven't delved in detail, but I believe an embedded perl can throw
off a separate instance of a perl interpreter which can be destroyed
after its work is done.  All the necessary subroutines are shared but
the data structures are separate.  So the only overhead in treating
such plugins separately would be down to the initialization of the
interpreter's data structures.  I think, but am not sure, that epn
will initialize a different interpreter for each plugin rather than
re-using a single interpreter, otherwise the plugin specs would not
warn that BEGIN blocks only get run when epn starts.  It ought to be
able to make the interpreters that handle particular plugins go away
after each run instead of being persistent.  But I skimmed through
the perlembed man page rather quickly, so could well be wrong. 

-- 
Paul Allen
Softflare Support