Isolated Apache Virtual Hosts?

An anonymous reader writes: "Anyone ever had to set up virtual hosting on a server that allows CGI execution, etc? This seems to be simple, until you want to keep users out of each other's data. The Apache config seems straightforward enough, but I still haven't figured out the best way to set up the user groups on the box to keep them trapped in their areas and out of each other's business. I thought I could put each user in his own group to block prying eyes on the system side, then add the web user to all the other user's groups allowing him to get to their files, using suexec to prevent one user from using the web server to look at another user's files. This works well, but there seems to be a limit on the number of secondary groups a user can be a member of. So, the web user hits a wall at roughly 16 "customers" or user accounts. Any suggestions on how to improve on this and get beyond the limit? Or is there a better way to approach this than the group/suexec thing? Any pointers to online resources dealing with this type of config would be great..."

Comments

Re:Pretty easy, actually.

[nathanh]

Let each person's home directory be their website, then just point the Apache virtual servers to the users' respective homes. Remember, of course, to add the Apache user itself to each user's personal "group" so it can see their stuff. Super easy, I've been doing it for years. ('Course now somebody's going to point out some huge security flaw in this arrangement and I'll be kicking myself from here to breakfast... :)

This is no good if you have php/perl scripts. The scripts run as the Apache user and you don't want people exploiting that to intrude/destroy other users on the system. You want each virtual host to run as a different user, not just be restricted to a different directory.

Suexec promises a solution, but it really does seem like using a mallet to remove a cork from a wine bottle. And as the author of this story discovered, suexec isn't a perfect solution.

Unfortunately the only way I've found to solve this particular problem was to instantiate a new Apache process per user. This is understandably a resource hog, not to mention a configuration mess.

The S/390 "VM" concept is almost perfect. Each VM can run a different Apache process as a different user, so that way you have perfect sandboxing. Unfortunately an S/390 is a little pricey (even the base model).

The real problem is that Apache forks a herd of processes but each process can serve pages for any virtual host. If the Apache process changes its uid to a normal user, then it won't be able to change back for the next virtual host. Killing and restarting processes would work but would also destroy throughput. That is, unless you used threads, but threads won't be available until 2.0 is stable.

The problem is a common question on the Apache mailing list (and I've been guilty of asking about it too, before checking the FAQ). The last time I checked the answer was "we know about this, it's not trivial to fix, don't ask about it before at least Apache 2.0".

Big Iron

[Eagle7]

Simple - buy a low end S/390 (sorry - zSeries, stupid IBM marketing), get yourself a VM license, and just give each customer thier own complete Linux box. Maintinence becomes really easy too, and it will never go down.

Of course, there is a downside - $500,000 for the Iron, and some outrageous license fee for using VM.

As an aside, I've heard the computer science dept. of one University was going to do this and give each student thier own Linux box to use, as an alternative to shell accounts.

You can see some Linux on VM/390 screenshots here.