How we solve the multiuser PHP problem

June 28, 2009

For those that have not run into it, the multiuser PHP problem is this: you have a shared, multiuser web server where many people have their own web pages, and some of them want to have PHP-based applications. This is a perfectly reasonable thing to ask for, but PHP runs in the web server under the web server's UID and to have at least a pretense of accountability and security you want a user's dynamic stuff to run as that user, so at most they can blow up their own files and compromise their own account. And PHP is just the (large) tip of the iceberg for this problem; there are lots of web apps that need some special Apache configuration or module or what have you (and let's not even get started about database requirements).

Our solution to this is simple but brute force; we have users run their own web servers and then hide them behind a reverse proxy from our main web server. To help people out, we provide a standard Apache configuration with all of the usual LAMP features turned on (and an optional MySQL database instance) and some scripts to set it up for you and control it.

(People don't have to use the configuration, or even run Apache; we have a couple of people using mzscheme instead.)

Running the entire web server as the user obviously provides all of the security stuff that we wanted. Using a reverse proxy setup keeps all of this transparent by hiding the existence of all of these user-run web servers; even when content is actually being served by a separate web server, it still has URLs on our main web server. Among other things, this means that you can start and stop using a user-run web server without having to change any URLs.

This scheme does have some drawbacks. One of them is that we wind up with a lot of inactive Apache processes and so on running on the web server machine, since each user-run web server is running a few even when no one is using it. (I don't think that load limiting is harder; since the main Apache server has to proxy for everyone, its limits act as a global limit across all of the user-run web servers.)

(Another one is that the software running on user-run web servers has to be reverse proxy aware, as do the people writing it, but that's a topic for another entry.)

(Necessary disclaimer: as before, this system is the work of many people here.)

Comments on this page:

From at 2009-06-28 14:59:23:

We use suphp solve this problem, which runs php as the user, but avoids the need to run multiple users. It's not quite as well supported as suphp (ubuntu's package, for example isn't always quite up to date) but solves the issue reasonably simply.


Written on 28 June 2009.
« Possible limits on our port multiplied ESATA performance
A theory on why users keep mailing specific people »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jun 28 00:56:02 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.