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..."
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".
- 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.Accept Eris as your Fnord and personally sate her
If you make them use something like PHP, you can easily make them stay at their side of the server...
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!
At the ISP I work for, we have been using the Roxen web server since 1997-98 and it has always had the "Run scripts as" option in the CGI module located in the modules for each site. It defaults to 'nobody' but if the web server is running as root, you can specify any username in this box. It is dificult to get PHP running on Roxen, but for everything else it works great. Documentation located at: http://docs.roxen.com
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.
_sig_ is away
How does threads fix the issue? How can a process have threads running under different user ids running concurrently? Granted - I don't know much about threaded apache - but isn't this a problem?
Or does apache fork out a process for each user id- then each process runs multiple threads?
You can do a lot by chrooting the ftpd you use to allow users to upload files (I highly reccomend proftpd because of it's nice apache-esque config files) locking them into their home directory. That's step one.
/var/www or /usr/local/www or whatever), but that won't stop users from peeking into others directories.
o m
Step two is to deal with PHP, perl, cgi's and whatnot which all run as whatever user the web server is running as. For PHP, for example, you can set the variable open_basedir to force it to not descend any farther than your base document root directory (i.e.
Sadly, the best solution I've found is to cheat and just try and obscure things. Make it not obvious what a given directory might be and then it is much harder for naughty users to look where they shouldn't be. An MD5 sum of the domain name chopped in some fashion, or hell, even a totally random string can be used. You'd then have a website stored something like this:
/var/www/{hash}/www.domain.com
/var/www/{different-hash}/www.differentdomain.c
The user who owns www.domain.com would then need to know what the hash is for www.differentdomain.com to be able to try and access those files. Make your hash generation random or at least very, very non-obvious and you're about as secure as you're going to get with Apache in it's current state.
I don't really understand myself, but I can make an educated guess. Apache 1.x starts up several processes in advance (MinSpareServers) and puts them into a pool, ready to serve any request for any virtual host. These processes are heavyweight so best throughput is achieved by preforking them. Each process then serves 30 requests for any virtual host before exit'ing, but these requests are served out as the same UID. The pro is that you get better performance. The con is that you have to use the same UID for every virtual host.
Yes, that's my understanding of what's changed for 2.0. With Apache 2.0 you will be able to assign a dedicated child process to a virtual host by using the AssignUserId directive. With older Apache this would have been either a waste of resources (large and expensive pool of processes per virtual host) or a performance disaster (not enough preforked processes in each pool). With Apache 2.0 you can afford to create a process per virtual host because the pool consists of threads, not processes (inexpensive single process per virtual host).
The sad bit from the documentation is "This MPM does not currently work on most platforms. Work is ongoing to make it functional". Otherwise the AssignUserId directive is what the author of the AskSlashdot wanted. Until 2.0 is finished and works, the only solution I've found is what I described in my previous post: create a standalone Apache pool per virtual host and just live with the waste of resources.
As I said, I'm not an Apache developer, this is just an educated guess based on my limited understanding of what's going on. A real Apache developer would probably slap me silly for providing a totally bogus explanation.
It will work if you provide different ip address for each vhost / daemon to listen to. Single ip vhosting in chrooted environment for each vhost might provide either diffecult or totally impossible (havent given a thought about how it could be done if its possible)
yush
Java provides the basis of a much more coherent security and concurrency model than Apache 1.x + Unix, and products such as WebLogic, JBoss and Jetty take good advantage of it.
Essentially, the thread serving a user's request has their authenticated ID associated with it, and cannot access any resource to which that ID hasn't been explicitly authorized, e.g. in mappings in the web.xml file. If the resource corresponds to an external file or process, it is easy enough to assign it ACLs in the app server and let the server decide whether / how to run it.
The server itself doesn't need to be root.
For example, see the WebLogic security docs - you probably won't find similar these features in free products now, but with the impressive capabilities that Java 1.4 provides it shouldn't be too long before they appear.