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

Use groups to exclude

[akh]

This works well:

• Create a webusers group and make all hosting clients members of it
• Set permissions of web files to 604 or 705
• Set ownership as follows:
  • user: the file's owner
  • group: webusers
• The web server should run under a group other than webusers

Set up like this each user can access their files (they have read/write/execute permission on them), but not those of other group members. The web server still be able to access them since it is not part of the webusers group and thus falls under the 'other' set of permissions. It is important to restrict access to the server to members of the webuses group and to administrators - there should be no regular users on the machine who are not in the webusers group. A server set up this way should do want you are trying to do.

Re:Big Iron

[Eagle7]

Simple - five 9s hardware. The problem is X86 boxen (as most PC users can attest) is shit breaks. Fans stop, harddrives fail, MBs blink out. Mainframes don't have this problem - they are designed to keep ticking. If you have 10 CPUs in your 390, and one goes down, IBM just comes by and puts in a new one while everything is still going.

Incidentally, the hardware console for a 390 is a Thinkpad. That's right - a whole Thinkpad just for the console. And often there are multiple Thinkpads for redundancy.

The other big difference is bandwidth - the bandwith in a mainframe is incredible.

If someone offered me to colocate my server in an x86 farm, or under VM on a 390, I would choose the latter any day. Instant setup, and most reliable hardware in the world. If you need more data space, or processing time, etc, you don't even need to bring the machine down - cut them a check, they tweak some settings in VM, and *voila*, you're set.
Once you get to know them, Mainframes are really cool. :)