http://www.perlmonks.org?node_id=282246


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

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.

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: mod_perl and shared environments don't mix - do they?
by perrin (Chancellor) on Aug 08, 2003 at 17:20 UTC
    It's true, Apache::Resource would allow malicious users to remove limits. It is meant to help people keep from shooting themselves in the foot, not to prevent intentional attacks. It might work better to set rlimits as root during apache startup.

    it made sense to me since you can load C binaries in a Perl module

    The extensions to PHP that allow things like database access are also written in C. As I understand it, writing custom PHP libraries that use C code is a very popular practice among high-volume sites.

    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

    Coding yourself vs. using a CPAN module is only faster if you can always write faster code than the people who write the modules. Given the high-quality of the most common Perl modules (DBI for example), this seems unlikely. There certainly are some large "kitchen-sink" CPAN modules out there, but anyone who is concerned about performance can easilly steer clear of them.

    I don't think that mod_perl's API for accessing apache data is inherently more dangerous than the PHP equivalent. They both give you access to the same information about the request. What is more dangerous is that mod_perl doesn't provide a safe sandbox where code written by one user can't possibly affect code written by another. This is addressed in mod_perl 2, but it's not stable yet. Meanwhile, people looking for shared hosting with mod_perl still need to go with a virtual server or SpeedyCGI.

      The extensions to PHP that allow things like database access are also written in C. As I understand it, writing custom PHP libraries that use C code is a very popular practice among high-volume sites.

      Yes, but the difference is that if a user has permission to run mod_perl as part of a shared server environment that user can load leaky C code - custom C modules for php would have to be compiled into the server by the administrator.

      I don't think that mod_perl's API for accessing apache data is inherently more dangerous than the PHP equivalent. They both give you access to the same information about the request.

      Mod_perl can modify apache internals - that's why it's so powerful. You can do anything with mod_perl that you could do with a C module (making it great for prototyping apache C modules). The only things PHP can modify are selected PHP settings and the server output.
        the difference is that if a user has permission to run mod_perl as part of a shared server environment that user can load leaky C code - custom C modules for php would have to be compiled into the server by the administrator

        In both cases you need nothing more than the ability to compile the module and the ability to add it to the path. Instructions for loading a custom C library from a PHP page are here.

        Mod_perl can modify apache internals

        Like what? You can add configuration directives, if you have the ability to compile a C module and add it to httpd.conf. You can control which phase your module gets called in (to create an auth handler), but that's no more of a security risk than any other access. You can modify values of the current request, but again, this doesn't hurt any one else. Looking down the API, I just don't see anything that would allow one to wreak more havoc than you could with PHP.