in reply to Mod Perl Usage on Virtual hosted domains

The problem is that you really can't have a "shared" mod_perl if you don't trust who you are sharing it with.

For example, I could execute the following code in my module: 

BEGIN {
  *strict::import = sub { die "ho ho ho" }
}

[download]
And now your code when it loads with the nearly-required use strict will execute my trojan horse.

There's no real way to protect against that. One shared persistent interpreter is one shared persistent interpreter.

You can run mod_perl in the "virtual host" solutions where each user has a completely independent Apache process group, sharing only the CPU.

But don't count on a mod_perl solution where you and others are all sharing the same Apache processes. It won't happen, for all the right reasons.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Replies are listed 'Best First'.
Re^2: Mod Perl Usage on Virtual hosted domains
by Aristotle (Chancellor) on Oct 19, 2002 at 21:12 UTC

    What I've always wondered is why mod_php can be offered on shared solutions, while there is no way mod_perl could. Are the PHP folks being more clever, or just not talking about security? If they're being clever, why can't we? And if we can, why don't we do it? If mod_perl could easily be offered for virtual domain hosting solutions, it would probably put a dent in the proliferation of PHP.

    (To abate the flames, I don't mind PHP, the same way I don't mind shell scripts. But I wouldn't use either for anything complex.)

    Makeshifts last the longest.

[reply]
      Perhaps because it isn't really, or only in a limited fashion (with lots of "extensions" disabled, giving only a very lite version of php)?

      I doubt they're being more clever, it's just that their product/language is lots simpler.

      I will now quote http://archive.develooper.com/advocacy@perl.org/msg01553.html 

      Description              Perl  PHP

Namespace management     Y    N 
File-scope globals       Y    N 
Regular expressions      Y    Y 

OOP support              Y    N(2)
Run time code mutability Y    Y   
Extensive lib collection Y    Y(4)

Closures                 Y    N   
anonymous subroutines    Y    N   
automatic code creation  Y    N   

Notes:
 (2) PHP support for objects is not much different than C++ support for
 (4) Not quite extensive, but it's getting there - PEAR is only a year or
     so old.
      Since there is no way in perl to prevent a program from modifying `import' among other things, you can't share a perl process among different users.

      update:
      Also, perl's regex engine is a "beast", and there exist some race conditions (sorry, I don't got a link handy to a discussion), and PHP just uses PCRE, which is Perl Compatible RE, but not quite Perl re ( and lots of features in the current perl re engine are **experimental**)

       
      ______crazyinsomniac_____________________________
      Of all the things I've lost, I miss my mind the most.
      perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

[reply]

In Section Seekers of Perl Wisdom