FastCGI for mod_userdir

Author: Jeff Anderson

So, I want to move away from mod_php for the obvious security reasons.

FastCGI is a good alternative. I want to make the transition as easy as possible for my users. The transition on my Bluehost account from the regular PHP handler to the fastcgi handler is quite easy. All I do is add AddHandler fcgid-script .php to my .htaccess. Here are the requirements that I am looking for in transitioning to fastcgi for php:

1) Easy Transition - little or no user intervention required. I'd prefer that no intervention is required. 2) fastcgi scripts should be run using suexec for security and potential tracking purposes. 3) No scripts should be run when adding/removing users from the system. I want this to "just work" with the mod_userdir setup that we have.

Ideally, this change could be made during scheduled maintenance, and everyone could be automatically using the new fastcgi php handler. Asking a few thousand users to add something to their .htaccess files just to keep their PHP site running is something that is generally not received well.

Here's what I've found so far:

  • Bluehost seems to script the adding of the PHP fastcgi handling script to the filesystem. When I run a PHP script on my Bluehost account, the process that is launched is called fcgiphp5. If I look at the /proc/<pid>/cmdline file, the full path is /ramdisk/bin/fcgiphp5-<username>. I have no idea if Bluehost is using a vanilla suExec or not. As far as I know, /ramdisk is not in my docroot, which is something that suExec definitely wants of a wrapper script for fastcgi.

The closest I can come to my set of requirements is forcing each user to "opt-in" with a couple lines in the .htaccess file, and the addition of a wrapper script placed in their public_html.

I've tried forcing the FCGIWrapper to be /usr/bin/php-cgi to no avail. suExec complains that it isn't in the docroot. This makes me think that Bluehost might be using a modified version of suExec because the FCGIWrapper there seems to be outside my docroot.

I've also tried using a common wrapper script. I placed the wrapper script in the docroot that is used at the root of the webserver. When running inside a mod_userdir directory, suExec treats the ~<username>/public_html as the docroot, so that didn't work. suExec also needs the script to be owned by the same person that is trying to execute it.

My conclusion about FCGIWrapper + suExec is that it's a good solution, but it isn't practical for making it the primary php handler on our system. I could potentially publish instructions for individual users to "opt-in" but I doubt that even 1% of the site owners on our server would bother setting it up.

The other common aprroach is using an Action line in the apache config that defines a cgi script in the web path that handles another file.

This has the same limitation in that each user needs to "opt-in" by creating the handler script in their public_html directory.

It seems like my requirements are too heavy, fastCGI handlers weren't designed to do exactly what I want, or I need to adjust my requirements to something more realistic.

If I adjust my requirements to allow the scripting of the creation of individual handler scripts, the process could definitely be more realistic. Ideally, I'd be able to create a directory that is outside the individual user public_html directories that holds all the wrapper scripts, but I think I'd run into the snag of suExec complaining that the requested script is outside the document root. How does Bluehost do it? I really don't like the idea of running a script to put files in a few thousand home directories.

I'm stuck. It doesn't seem like I can use a suExec'd fastcgi handler for PHP in a mod_userdir without user intervention, or invasive scripting. How can I make this work?

Is it a better idea to use mod_suphp? I ran across it toward the end of my fastcgi research. I'll probably be looking into that next.

Posted: Mar 24, 2009 | Tags: Open Source Servers Hosting PHP FastCGI

Comments are closed.