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

Andreas Ericsson ae at op5.se
Fri Apr 2 05:17:04 CEST 2004

Paul L. Allen wrote:
>> Unions and structs are a part of ANSI. It's perfectly acceptable to 
>> have an array of structs containing arrays of structs with arrays of 
>> arrays (or whatever) in them, allowing for infinite depth arrays.
> Gosh, you have unions and structs.  Ah well, that's everything you'll ever
> need.
For functionality, yes.

>> Hashes are convenient, but not necessary since it's perfectly possible
>> for you to hop the pointer yourself.
> 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.

> 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.

>> 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

>>> 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.
>> 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. Also, if I read Karl's 
comments on the perl framework correctly, it has almost grown out of its 
own usefulness.

>>> 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.
> 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. In 
what way did I ignore the productivity issues?

>>> You can do anything from any language, if you try hard enough.
>> 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.

>> On a serious note though; Do you know how many bugs and potential bugs 
>> me and the other Owl developers have fixed in perl 5.8.3? Last time I 
>> checked we were at patch-level 23 (each patch fixes 3 or more bugs). 
>> Patches have been submitted, but it's a serious load of code so I'm 
>> thinking it'll be a while until they're allowed in the tree.
> 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?

>> Also, we value security above functionality, which isn't always
>> functional enough for the kind of ad-hockery many perl programmers
>> (read script kiddies) indulge in.
> Yeah, script kiddies like the programmers for the Swedish state pension
> scheme.  After the main project code went way off schedule, some of these
> "script kiddies" knocked up some code in perl as an interim system.  It
> worked so well that the main project code was dropped and the interim
> perl code upgraded to have all the functionality in the spec.  The perl
> code took a small fraction of the time to write that had already been
> spent on the main code.
many != all
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.

>> Auditing a perl plugin makes the one-time penalty even worse, since it 
>> requires auditing of perl itself as well (not to mention the modules 
>> it uses).
> That's a fair point.  But given the choice between a plugin that does
> what I need written in perl or no plugin at all, I take the former.
Already discussed and agreed upon.

>>> 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.
>> What do you want me to respond to? You weren't asking me anything if I 
>> remember things correctly, merely stating that it was (which is true, 
>> so I don't have a respond for that).
> 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?

>> 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.

>>> 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.
>> You put too much faith in Larry Wall et al.
> 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?

>> Also, a false sense of security is worse than real sense of insecurity.
> 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.

>>> In practise, the only plugin I have seen that needs to run
>>> an external command as another user called sudo.
>> Which means a legitimate sudo call will exist on the stack (free fire 
>> zone).
> 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 

>> Yes, but at what cost? Do we need to mark certain scripts as unsafe 
>> for the EPN, and how do we go about doing that? Config variables in 
>> nagior, or with shell-scripts wrapped around them?
> How about separate directories?

Should work out ok. Then we'd only have to add one new variable to the 
main configuration file. 'perl_safe_cache_dir' or something. Code could 
be kept rather clean (well, not any messier than it is at least) and 
consistent, and everybody would be happy.

Andreas Ericsson
+46 (0)733 709032
andreas.ericsson at op5.se

More information about the Devel mailing list