Is this correct? I don’t think that Apache fires a whole PHP process for a GET /img/image.jpeg.

I don’t think so either – HTTP is supposed to be stateless, so that each resource requires an individual request. My understanding was that Apache evaluated each request on its own merits, regardless of source – the TCP/IP handshake that was mentioned is carried out at a lower layer than any HTTP processing.

If this is indeed an issue can anyone provide a link to the evidance etc?

What about open_basedir?

In short, it takes shared hosts into a cat and mouse game.

open_basedir only effects PHP, which is still running with the same user as Apache. Via exec you might be able to execute standard Unix programs to which the restriction wouldn’t apply. Or if a host has locked that down but still supports Perl, you could have PHP execute them for you. Of course you could try to block that with safe_mode but, in reality, think safe_mode (and open_basedir) only discourages those who probably aren’t that dangerous anyway. Well explained here: http://ilia.ws/archives/18-PHPs-safe_mode-or-how-not-to-implement-security.html

But you’re right, I underplayed the memory issue. Also probably underplaying the security issue for shared hosts—an interesting discussion here

What about open_basedir?

It also means, that all of your images, style-sheets and static files are served by those “fat” child-processes that include an instanec of the php interpreter as well, which is why you often hear the advice of moving static files/images to a different webserver. Hence why many people are so happy with [lighttpd+]php as fcgi (it uses less system resources).

That’s true although PHP’s approach of refreshing the interpreter on each request I believe is what makes it more appealing vs. mod_perl and similar – no globals etc. Again it’s aiming for the best compromise I guess.

And here PHP’s persistent resources are an issue – George Schlossnagle also suggests a lightweight HTTP server on a subdomain for static content here.

But you’re right, I underplayed the memory issue. Also probably underplaying the security issue for shared hosts – an interesting discussion here;

> On Dec 22, 2005, at 11:44 PM, pbdgny wrote:

shared hosts were all on mod_php for a while because thats what they thought they should do. but a funny thing happend – they realized that mod_php lets user_a acces all of user_b’s files — because everything runs as the apache instance user and is read/writeable by it. so most hosts started migrating to PHP/CGI via FasctCGI, so account holders can more easily run their scripts as a shell user.

There’s also some interesting research thanks to Ben Ramsey – Peruser MPM for Apache – basically still no ideal solution for shared hosts.

With PHP it’s very hard for a script to take down the runtime environment—the web server—I’d argue that you’d have to be deliberately trying to do so, perhaps filling up disk space or otherwise.

I’ve seen it done non-intentionally or maliciously, and of course you can do these in any language. One example, logging error or other messages to the filesystem but forgetting to rotate the log file. That’s particularly irritating because the file might quietly be growing while your server is happily serving pages until you get the page that the web server isn’t responding and won’t restart. A second is having the server send you and email after every request that encounters a fatal error. Encounter a fatal error during very heavy traffic and you’ve just generated tons of mail for your server to deliver.