Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

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


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

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.


Comment on Re: Re: Re: Re: Re: Re: mod_perl and shared environments don't mix - do they?
Re: Re: Re: Re: Re: Re: Re: mod_perl and shared environments don't mix - do they?
by perrin (Chancellor) on Aug 11, 2003 at 03:08 UTC
    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.
        I agree that mod_perl is not appropriate for environments with potentially malicious users in a shared environment; I just don't agree with your reasons. I think they show some common misconceptions about mod_perl, e.g. memory leaks and dangerous apache API. The reason it's unsafe is all on the perl side, i.e. you can mess with other people globals, functions, etc. as much as you want to.

        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

        You're thinking of adding things like an access handler or filter to someone else's stuff? You can only change that sort of configuration during startup, which would require you to have admin privileges on the server. After startup, docroot can't be changed.

        A user might be able to bypass bandwidth throttling too

        If you give people just Apache::Registry access and no use of .htaccess files they would not be able to, since it would be too late in the request for that. They could skip a cleanup or logging handler though.

        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?

        Not really. Your code ends when the request ends. However, you could take advantage of Perl's unprotected nature to globally redefine the print function or change the Apache::Registry handler function to do something completely different. So again, wide open for exploits, but all on the perl side. None of it related directly to the apache API.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (11)
As of 2014-09-17 20:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

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











    Results (99 votes), past polls