P is for Practical | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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. In reply to Re: Re: Re: Re: Re: Re: Re: mod_perl and shared environments don't mix - do they?
by perrin
|
|