in reply to Challenges

Cool idea.

The most interesting discussions (I think) focus on the relative merits of a variety of techniques. "Is this more efficient than that?" "Can I do it this way?" "What are the security implications of such-and-such?"

This is where the combined talent and expertise of the Perl Monks' monks can really shine.

On that note, I would have to disagree with any kind of automatic benchmarking. The security implications are just too overwhelming. I would be willing to review and benchmark code and post the results (others would too, I'm sure), but I'd hate to see the Perl Monks server crash a lot from automatically executing untrusted code...

Neat idea...

Russ

Replies are listed 'Best First'.
RE: RE: Challenges
by Aighearach (Initiate) on Jun 29, 2000 at 10:15 UTC
    Isn't it a *nix server? Surely there is a way to make it fairly secure. Stick it in a wrapper, or something. 
    Paris Sinclair    |    4a75737420416e6f74686572
pariss@efn.org    |    205065726c204861636b6572
I wear my Geek Code on my finger.
[reply]
      Well, how much do you trust taint mode? Knowing that anyone could upload any code and execute it... <nobr>system('rm -fr /')</nobr> would probably not make it past Taint (and nobody lacks permissions to do this, anyway), but I wouldn't sleep well at night...

      How about Denial of Service? 

      while (1) {
  $Str .= 'A few more bytes consumed';
}

      [download]
      I wouldn't want to allow arbitrary code on any of my servers...

      Now, recent experience has shown me that there are a large number of monks willing and eager to benchmark code and post the results. I think a section like the one you describe would be quite popular.

      Russ

[reply]
[d/l]

        >Well, how much do you trust taint mode?
        Like I said, you could run it inside a wrapper. No need at all to trust taint mode.

        >How about Denial of Service?
        How about it? That's a threat always. And, you just put a limit on how many times each user can submit code for benchmarking.

        Also, you could make it so that anybody under level 4 or 5 would have to have the code approved by somebody higher, before the benchmarking ran.

        Security is a concern, but isn't it more of a hurdle than a road block? 

        Paris Sinclair    |    4a75737420416e6f74686572
pariss@efn.org    |    205065726c204861636b6572
I wear my Geek Code on my finger.
[reply]
      hmmm, in a situation where your asking for the server to execute untrusted, unknown code (to test for effiency of course) a wrapper would not be the answer...A wrapper is in most cases some type of frontend..a frontend that takes requests and looks at it and executes somthing else based on that request..or somthing like that..In this case, which I still dont think is a good idea, a highly restricted chrooted enviroment for the code to run in would be the answer...but still, not a good enough answer :)
[reply]

        >A wrapper is in most cases some type of frontend..a frontend that takes requests and looks at it and executes somthing else based on that request
        Well, a wrapper for a frontend would be a frontend.

        >highly restricted ... enviroment ... not a good enough answer
        It's not? Why? There are lots of servers that let people login free, with little verification, and then let users have a *nix shell of some sort. Well, a few anyway. They seem to manage fine. If they can do it, surely the legendary Perl Monks can also achieve the modest goal of benchmarking?

        Doing the benchmarking by hand would be much less elegant. But, still quite useful and effective. 

        Paris Sinclair    |    4a75737420416e6f74686572
pariss@efn.org    |    205065726c204861636b6572
I wear my Geek Code on my finger.
[reply]
[reply]

In Section Perl Monks Discussion