in reply to Re^5: LAMP and hosting: Convenient Perl solution, similar to PHP setup?
in thread LAMP and hosting: Convenient Perl solution, similar to PHP setup?

Read the original question again. The OP was specifically asking about shared hosting environments, and it's specifically in such an environment that there are the security issues I mentioned. In such an environment my suexec'd FastCGI backend can't muck with your suexec'd FastCGI backend.

And I wasn't talking about modifying global configuration, I was talking about modifying code. If your site ran CGIs under Apache::Registry and I can divine the generated namespace your site's handler gets compiled to I can write my own CGI which shims code into your site's namespace in place of yours. Or I could override DBI::connect with my own version that writes off your database credentials somewhere. Or I could override CORE::open and . . . well, one sees where that's going I hope. That there's no easily configured and lightweight (relatively speaking) way to sandbox mod_perl is the deal killer for shared hosting that the OP desires.

The cake is a lie.
The cake is a lie.
The cake is a lie.

Replies are listed 'Best First'.
Re^7: LAMP and hosting: Convenient Perl solution, similar to PHP setup?
by perrin (Chancellor) on Mar 12, 2008 at 17:52 UTC
    In such an environment my suexec'd FastCGI backend can't muck with your suexec'd FastCGI backend.

    Okay, if ISPs normally run their FastCGI stuff with suexec then I agree it is more secure in a shared environment.

    And I wasn't talking about modifying global configuration, I was talking about modifying code.
    If you run separate suexec interpreters for each user, FastCGI prevents this. If you aren't running suexec, a common configuration for things like Mason is to send all requests through the same FastCGI backend.