Re^4: LAMP and hosting: Convenient Perl solution, similar to PHP setup?

Erm, FastCGI sets up persistent external processes; mod_perl allows you to execute code that calls (pretty much) any part of the Apache C API as well as muck with the perl interpreter state (of the particular child you're called from, but with that caveat complete access; just think of the mischief a malicious user could do rewriting other users' Apache::Registry-derived code). Also FastCGI processes can be run as completely separate users (via suexec), mod_perl code runs as the httpd user.

Just those two things alone present some serious security implications in a multiuser situation (which is why you usually see suexec'd FastCGI used in shared hosting situations, and mod_perl when it's running your own iron).

(Disclaimer: I haven't mucked with Apache 2 / m_p 2 sufficiently, but I don't believe they changed enough to eliminate the above issues.)

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

Comment on Re^4: LAMP and hosting: Convenient Perl solution, similar to PHP setup?

Replies are listed 'Best First'.
Re^5: LAMP and hosting: Convenient Perl solution, similar to PHP setup? by perrin (Chancellor) on Mar 12, 2008 at 16:56 UTC
You can't modify apache's global configuration from within a request. People sometimes ask for this, but it can't be done with the way apache is structured. All that you can affect through the apache API is your own request, just like in FastCGI. How would FastCGI prevent mucking with the perl interpreter? In both cases, the interpreter is persistent and perl will not prevent you from changing things that affect future code in the same interpreter. Running as suexec would make a difference. The equivalent mod_perl setup would be to run a separate mod_perl backend for each user, which I've done in dev environments but it's annoying to set up. The security would then be identical, but it would use more memory than a shared server, just like suexec FastCGI would. In both cases the lack of sharing from copy-on-write is costly.	[reply]
Re^6: LAMP and hosting: Convenient Perl solution, similar to PHP setup? by Fletch (Bishop) on Mar 12, 2008 at 17:28 UTC
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.	[reply] [d/l] [select]
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.	[reply]