Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

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

by Aristotle (Chancellor)
on Nov 10, 2002 at 00:28 UTC ( #211696=perlmeditation: print w/ replies, xml ) Need Help??

At Re^2: Mod Perl Usage on Virtual hosted domains, I asked why mod_php can be offered on shared solutions, while there is no way mod_perl could, to which crazyinsomniac replied that there is no way in perl to prevent a program from modifying `import' among other things, so that you can't share a perl process among different users.

And I just had the proverbial lightbulb go on above my head (though I suspect it will still prove to be a shot in the dark): wouldn't Safe let us do just that? If each user's code is loaded into a compartment, it shouldn't be possible for the different compartments to interact. In fact, we might get to simplify the process of mod_perlifying existing scripts as they believe they're running in main:: that way.

The idea seems so obvious in retrospect that I'm wondering if I'm really the first this occurs to or there is actually a totally obvious pitfall that I'm missing that noone ever bothered because of.

I've been pondering this problem on and off for a while. PHP has spread through the shared hosting world like wildfire, as is easily evidenced by the fact that the simple web messageboard domain is dominated by PHP nowadays. The feasibility of being offered in shared hosting environments would be a great boon to mod_perl.

Makeshifts last the longest.

Comment on mod_perl and shared environments don't mix - do they?
Re: mod_perl and shared environments don't mix - do they?
by chromatic (Archbishop) on Nov 10, 2002 at 01:41 UTC

    For programs that only run in Apache::Registry, that just might work. For programs that extend Apache itself, it probably won't work. To my knowledge, PHP doesn't give access to the full Apache API, so it does a whole lot less than mod_perl and is much easier to sandbox.

      Then I find that alone makes it worth investigating. (Make that one more item on my long list of ideas..) Most ready-to-install scripts come as mod_perl-friendly CGIs, with the main appeal of mod_perl besides the acceleration of the scripts themselves being persistent database connections. Just being able to run those in a shared environment would be a big boost.

      On the other hand, how much work would it be to offer a stripped down mod_perl that only offers enough of the API as to be sandboxable like PHP? Idly mulling, it seems it might even work to strip down mod_perl via httpd.conf rather than at compile time.

      Makeshifts last the longest.

Re: mod_perl and shared environments don't mix - do they?
by trs80 (Priest) on Nov 10, 2002 at 02:27 UTC
    Facts:
    • PHP is a language
    • mod_perl exposes the Apache API and is not a language
    • PHP is for building applications
    • mod_perl is the engine that drives applications, but it offers no help in the application building process.
    • PHP runs under IIS and Apache
    • mod_perl runs only under Apache
    • PHP has a single voice documentation that covers all aspects of the language.
    • mod_perl has multiple voice documentation that covers all all aspects of the system.
    • PHP applications don't require modification to the httpd.conf (PHP requires the addition of the AddHandler for .php files however)
    • Application frame works for mod_perl (Apache::ASP, Embperl, Mason etc.) require modification of the httpd.conf

    These are just some of the issues surrounding acceptance of mod_perl over PHP. Combining mod_perl with Safe doesn't eliminate the learning curve that mod_perl has, not to mention the difficulty in picking the best templating/framework system to use in conjunction with it. mod_perl offers more flexibility, but at the cost of increasing complexity. In environments where the skill level of the implementor is unknown, such as shared hosting there are far too many support and configuration issues to make mod_perl parctical for most business models. Companies that offer mod_perl hosting specialize in it.

    So while I agree that Safe might help, I think we have bigger fish to fry.
Re: mod_perl and shared environments don't mix - do they?
by Revelation (Deacon) on Nov 10, 2002 at 03:01 UTC
    A note:

    There are numerous cheaper than dedicated server frameworks that off mod_perl. Not advertizing here, but check out HSPComplete. Some sites that offer it are: eryxma.com, and Hostmania.net (the entry level page doesn't work there.). You might want to check out other examples of this as well, by going to webhostingtalk.com. Other possibilities include root via UML (User Mode Linux), or Ensim's virtual server environment. I'm not sure how any of the technologies employed actually work, though.

    In addition, my webhosting provider expnet offers a 'virtual server' package that gives each user a chrooted 'root' access. To use mod_perl, or to install apache ability to modify the kernel is not a prerequisite, so this works as well. However, access to shared cache (PostgreSQL, or IPC::Somestuff, I assume) is not possible, as that's much more complicated. I wonder if the virtuozzo or Ensim environments allow access to them?

    So access to mod_perl is now offered for cheaper and cheaper prices, although this includes root access, and a prerequisite is *some* sort of server knowledge. When you consider some of these hosting accounts cost less than $15, it really is remarkable. If you can administer a server, I'd advise investigating. Otherwise, you'll have to get somebody to manage these environments for you. With 'virtual server' environment so cheap, there really is not much of an initiative to allow users access to mod_perl through 'virtual hosting', since it really doesn't corner any aspect of the market (the ammount of mod_perl coders who are not linux savvy is minute...)

    In addition, when you say:

    PHP has spread through the shared hosting world like wildfire, as is easily evidenced by the fact that the simple web messageboard domain is dominated by PHP nowadays. The feasibility of being offered in shared hosting environments would be a great boon to mod_perl.

    I would assert that mod_perl, even if it was available for shared hosting, would not spread like PHP. The main reason I find people using PHP is that it's learning curve is the least steep of all languages. Mod_perl, on the other hand, is very complicated (taking advantage of the Apache hooks, as well as the power of once-compiling code), and it follows a natural progression from perl as a language. This means that users won't be able to make a simple change from PHP to mod_perl. However, It might be valid to offer mod_perl through template toolkit; although, I find this to be less satisfactory than PHP for simple tasks.

    Gyan Kapur
    gyan.kapur@rhhllp.com

      Thanks for the notes.

      In reply to your comment however:

      I believe PHP has spread more because ready-to-install scripts like vB, phpBB, phpNuke, Typo3 and others are available that allow "non-techies" to run dynamic content on their sites.

      Before the advent of virtual hosting PHP, the most widespread messageboard software was UBB - written in Perl, with very ugly internals and hard to customize. But it was successful, because at the time it was released, no other messageboard software offered a "control panel" for easy configuration - you had to edit text files and/or the scripts themselves.

      PHP won, because it was easy to offer for hosts and easy for technically unsavvy site owners to run scripts for it. You already mentioned Template Toolkit II - having Apache::Registry applications use it (or maybe Mason?) would make them about as easily customizable as comparable PHP applications.

      That alone should be a great boost; and of course, for the savvy folks it would be a conditioning drug, who will soon want harder stuff like real mod_perl handlers. :)

      Makeshifts last the longest.

      Stay away from the IPC::* stuff. With the exception of IPC::MM, all of them are much slower than file-based approaches like MLDBM::Sync and Cache::Mmap.
Re: mod_perl and shared environments don't mix - do they?
by valdez (Monsignor) on Nov 10, 2002 at 20:09 UTC

    Using Safe is a nice idea, but what about access to file system? How would you implement an equivalent to safe_mode, user_dir and doc_root of PHP with Safe?

    Ciao, Valerio

Re: mod_perl and shared environments don't mix - do they?
by perrin (Chancellor) on Nov 10, 2002 at 21:19 UTC
    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.

      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.

      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.

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://211696]
Approved by adrianh
Front-paged by rbc
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (7)
As of 2014-10-25 13:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (143 votes), past polls