Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re: mod_perl and shared environments don't mix - do they?

by perrin (Chancellor)
on Nov 10, 2002 at 21:19 UTC ( #211797=note: print w/ replies, xml ) Need Help??


in reply to mod_perl and shared environments don't mix - do they?

It would be quite easy for someone to accidentally code something that will use all available memory or consume all CPU in a tight loop. There are ways to deal with this (rlimits), but Safe will not prevent it.

Perhaps more to the point, who is the market for this? I wouldn't pay a nickel for a hosting environment that required my code to run under Safe, or one that wouldn't let me modify httpd.conf and startup.pl.

Incidentally, PHP doesn't sound very safe either. You could do the things I mentioned above with it too. Can someone who knows more about it explain why PHP is considered okay? Does it run setuid or something? Or maybe it's just that it uses less memory.


Comment on Re: mod_perl and shared environments don't mix - do they?
Re^2: mod_perl and shared environments don't mix - do they?
by Aristotle (Chancellor) on Nov 10, 2002 at 22:07 UTC

    I don't exactly know. I have been wondering about the same questions a lot (having some, but not much PHP experience) but whenever I asked, I got this same reply: Perl as a language is much more complex than PHP so it would be impossible to stop someone from stepping on someone else's toes.

    My idea was that given Safe, that should be possible.

    I have repeatedly wondered about the dangers PHP exposes a site in shared hosting to on other levels. I have been bitten by mod_cgi in a shared environment before, so I'm aware that there are many ways to interact with someone else's data and/or code under these circumstances. For the relatively trivial mod_cgi environment there is suEXEC which, with some care in setting up permissions, can effectively and completely cage in everyone. But so far I've not seen much about the topic where PHP is concerned. In the case of mod_perl in its current forum it is at least known that one needs one Apache per user to make sure they play nice.

    As for not paying a nickel because it requires you to run in a compartment: the idea is that you have enough freedom within this compartment that you don't notice. That should be doable at least for Apache::Registry scripts.

    The market for this would be the same folks who buy PHP-enabled hosting and a PHP application to install on it and have little to no interest in developing that kind of solution on their own. The market, in other words, that is nowadays covered mostly by PHP.

    Certainly you won't use it for custom applications relying on "advanced" features, but I think that if there was a low-end mod_perl market (even just a crippled version), there would be a larger high-end market as well and, most importantly, there would be more mod_perl solutions.

    Makeshifts last the longest.

Re: Re: mod_perl and shared environments don't mix - do they?
by zaimoni (Beadle) on Nov 11, 2002 at 02:17 UTC

    PHP is deliberately specialized for web pages. This theoretically makes it easier to develop web interfaces quickly using PHP. It's not meant for general pattern processing.

    The PHP interpreter is written directly in C. Perl runs (after compilation) as a bytecode interpreter. I think that this is the other main advantage of PHP: response time should be improved by using one layer of interpretation instead of two. I'm not familar with the internal data representation of PHP, so I can't immediately compare the two languages that way.

    Unfortunately, PHP's strength (interpreter written in C) is also its critical downfall, from a network security perspective. I have advised two clients not to use PHP for publicly exposed scripts because of repeated "arbitrary code execution" buffer overflow bug reports in PHP's POST parameter parsing code...I think I've seen at least three distinct reports of this in 2002. So far, both clients have taken my advice.

      I don't quite follow.

      perl is written in C as well. It compiles scripts to bytecode which it then executes.

      The PHP interpreter is written in C, but does not compile PHP scripts to machine code. It still interprets them.

      There's no difference there.

      As far as security is concerned, I actually believe there is a whole lot of reasons to distrust PHP. Among others, POST and GET parameter names used to become global variable names - and a lot of folks I've seen writing PHP code still look at me like an alien when I tell them they switch that behaviour off. (Apparently, writing $HTTP_POST_PARAMETER[] or whatsitcalled for every variable is too much work.) A lot of sins any sane Perl programmer would advise against were freely committed in the PHP world in the name of convenience, and are only slowly being undone.

      PHP is nice, sort of like shell scripts - so long as your task is miniscule, it is quite handy and can get the job done in record time. It isn't anything I'd like to build a complex application with however.

      Makeshifts last the longest.

      I was actually asking why PHP is considered okay to run in shared environments from a security standpoint, not why people like to program it.

      Your facts about PHP and Perl's architectures are not correct. Both of them are written in C, both of them compile to bytecode before execution, and even with a bytecode cache like the Zend cache, Perl is still faster than PHP.

      Perl is equally vulnerable to buffer overflows, being written in C as well. The reason you don't see many reports of these problems in Perl is that a lot of people spent a lot of time finding and fixing them. The core Perl 5 codebase has had many years to mature.

      The PHP interpreter is written directly in C. Perl runs (after compilation) as a bytecode interpreter. I think that this is the other main advantage of PHP: response time should be improved by using one layer of interpretation instead of two.
      Perl does not use bytecode and there isn't an extra layer of indirection. You'll be better off if you just strike this bit as no part of this is meaningful.

      I'm not familar with the internal data representation of PHP, so I can't immediately compare the two languages that way.
      I'm not familiar with PHP's guts - apparently you aren't familiar with perl's.

      Unfortunately, PHP's strength (interpreter written in C) is also its critical downfall, from a network security perspective. I have advised two clients not to use PHP for publicly exposed scripts because of repeated "arbitrary code execution" buffer overflow bug reports in PHP's POST parameter parsing code...I think I've seen at least three distinct reports of this in 2002. So far, both clients have taken my advice.
      Again, this misses the point. Perl is subject to all the same problems. The difference is that perl is vastly more mature and these sorts of issues have just been shaken out by now. There's also some benefit in that CGI.pm's parameter parsing code is written in perl so you only have an exploitable bug if there's something wrong with perl's string handling. Apache::Request though - that's written in C and again it plays in exactly the same ballpark. The difference is again, relative maturity. All this means is that in a few years PHP will be sitting pretty.

Re: Re: mod_perl and shared environments don't mix - do they?
by bean (Monk) on Aug 08, 2003 at 06:00 UTC
    Actually, you can't use all available memory with PHP - the memory is limited to a setting in php.ini (8Mb default, I think). As for consuming all CPU, the execution time is also limited to a set amount of time (30 seconds default). Leaking memory is another fun thing you can do with mod_perl but not with PHP - or that used to be the big complaint, years ago. Plus, IIRC apache+php is a more lightweight binary than apache+mod_perl - taking less memory means you can handle more connections before swapping out. And since there are fewer useful modules/classes to use, PHP code tends to be leaner and meaner, so it usually executes more quickly. PHP partially makes up for this lack by having a(n inconsistently named) function for absolutely everything (this is also a weakness).

    Ok, I admit it - I use PHP (not by choice - it's the company standard at my work). I feel so *dirty* - I wash and I wash, but I can't get my namespace clean...

    Obviously mod_perl is much more powerful - but with great power comes great responsibility - and that's in short supply.
      Limiting the amount of memory and CPU that mod_perl uses is also quite easy (using rlimits as in Apache::Resource).

      I think you are misinformed about leaking memory. Most of the things people consider leaking memory under mod_perl are simply using memory as your program needs it to do more work. PHP will use memory too, if you load a big data structure from a file or database. Leaking requires you to code a circular structure or use a module with bad XS code. Running mod_perl by itself is quite stable.

      PHP is not as fast as mod_perl. Numerous benchmarks have shown this, including the ones Yahoo did to decide on using PHP.

      The subject of this thread was security, and why PHP is considered secure in a shared environment. The answers seem to be that it can be run as CGI (which of course is true of Perl as well) or that it can be run in a safe shared mode. The latter is an advantage over mod_perl for ISPs. At the moment, people looking for a cheap mod_perl ISP have to go for either a virtual server environment (where you get your own server with root access, but not a dedicated box) or SpeedyCGI.

        I thought the subject of the thread was why mod_perl doesn't work in a shared environment (maybe I should read more than the headlines...)

        Anyways, if you use a perl module to limit the memory and CPU usage of a mod_perl script, it would seem that in a shared environment you're letting the fox guard the henhouse - unless Apache::Resource prevents the children from accessing the same functionality.

        I may well be wrong about mod_perl leaking memory - that tidbit is based on hearsay from 4-5 years ago. However, it made sense to me since you can load C binaries in a Perl module. I guess you could run a binary from php using a system call, but the sysadmin can disable functions and the changing of environment variables from the php.ini, making this easy to stop.

        As far as speed goes, mod_perl may well be faster than the equivalent php code, but that wasn't the point - the point was that it's more likely that the php code will be leaner, since the temptation to load 20 modules isn't there (there aren't 20 modules worth loading). So the php code tends to be written precisely to the purpose at hand, and may easily be half as complex, giving it a speed advantage.

        The long and the short of it is, system administrators don't want you to have access to apache internals - it makes them nervous.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://211797]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (12)
As of 2014-10-30 16:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (208 votes), past polls