Wandering Thoughts archives

How we solve the multiuser PHP problem

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.)

Maybe understanding blogrolls

When I first started reading blogs, blogrolls made intuitive sense to me. You had to keep track of the URLs of the blogs you read somehow, and making your reading list public was the friendly thing to do. This view was so clear to me that at one point I considered writing a techblog entry about how I didn't have a blogroll because I used different methods to keep track of my various blog reading.

(Possibly I would have talked about how the rise of feed readers would affect blogrolls. There's two views: on the one hand, the feed reader keeps track of URLs so that you don't have to, but on the other hand the feed reader may make it easy to publish the list on your blog via some sort of plugin and API.)

In retrospect, this was a rather innocent view of the whole thing. With more experience in blogging, I've increasingly come around to the obvious view that blogrolls today are less about having your reading list in a convenient place and more about a way of recommending (or advertising) blogs that you think are worthwhile.

(Mind you, I could be wrong; I have a skewed perspective on this because I have rather odd ways of keeping track of web sites and I am a heavy user of feed readers. I don't know if more normal people really do use their blogrolls for their own reading, but it's certainly possible.)