Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

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 ( #282266=note: print w/ replies, xml ) Need Help??


in reply to Re: 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?

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.


Comment on Re: Re: Re: Re: Re: mod_perl and shared environments don't mix - do they?
Re: Re: Re: Re: Re: Re: mod_perl and shared environments don't mix - do they?
by bean (Monk) on Aug 10, 2003 at 18:55 UTC
    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.

        Interesting - I was not aware of the dl() function for PHP. Of course, it would be disabled by any halfway competent administrator (because safe_mode would be enabled, which cannot be overridden by a user).

        I haven't tried it, but with mod_perl a user ought to be able to modify his/her virtual host document root and mess with other users' stuff (it could modify anything dynamically generated). A user might be able to bypass bandwidth throttling too (although that could be fixed with proxy servers). What else... Would it be impossible for a mod_perl script to persist in the apache child and monitor information passing to and from the sites of other users?

        The bottom line is, PHP is designed to be friendly to administrators. Mod_perl is designed to do anything and isn't appropriately sandboxed for shared environments.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (2)
As of 2014-09-18 00:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (101 votes), past polls