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

[Darrell Mozingo]

You guys mind discussing your language flame war between each other? I'm
tired of getting these messages, they're not why I signed up to the
mailing list.

Darrell Mozingo

On Fri, 2004-04-02 at 08:08, Andreas Ericsson wrote:

> 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 
> stack.
> 
> >> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20040402/486587bb/attachment.html>