Slashdot Mirror
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..."
Yes, well, suexec DOES help. :)
Here's a link to Apache's own info on security (including suexec).
The easiest thing by far (if you have the money and no itch) is to become a reseller at Verio. Their servers are set up to handle just this kind of thing, and they do it extremely well. I have been running a virtual server with them for years, with "virtual" root access on the same box as numerous others - no problems.
A friend of mine told me that the vserver software they use (currently under freebsd) is open, but I couldn't find any mention of that anywhere. Supposedly there is a similar vserver project going on under RedHat.
Or you might want to ask the maintainer of PVHost if he will implement what you need. The project is defined as:
"PVHost is an ISP/poweruser tool that lets admins easily create new virtual web servers using Apache, PHP, mod_auth_mysql, and custom ftpd. It supports PHP, FTP and FrontPage rights control, etc. Custom ftpd allows creation of ftp accounts without the need"
Hurra for Knark!
This doesn't really work well at all if users have the ability to run CGI scripts (perl/php/etc). CGIs typically run as the uid/gid of the web server process (typically apache or nobody, death to any man running apache as root). Due to this, Joe Cracker could simply use his 31337 perl coding skillz to read the contents of a target file in any other user's directory.
Now, you might say this won't work for files chmod'ed in such a manner that the web server process can't read them. Okay, granted that's true. But what happens when Joe Customer wants to set up a file containing his database login information, to be accessed by a perl script delivering content to his visitors? The file has to be readable by the web server process...
Really, using a CGI wrapper (such as scgi-wrap) or suexec, both of which allow users to execute cgi scripts as their userid, is the best current solution aside from using actually virtual private servers (say on *bsd, where jails are tight).