> >>In their homedir there is a `ln -s` to their /var/www/home/username > >>webspace. That webspace is chowned username:www and chmodded 770 so > >>httpd can access/write to their dir as well. > >>Is that advisable / workable? Other ideas? > > > >You don't want the www user being able to write to your web space. > >Think about it. > > > >DS > > > Just did - <blush> > Thanks for pointing that out. > So that should be chmod 750.
You've raised an interesting point though. This is fine if all they want to do is serve static content. But it gets hairier if they want to run CGIs, and even hairer again if they want to run long-lived processes which handle multiple requests (such as Rails, or mod_php for php intensive sites) You don't want user 1's web applications to be able to access data in user 2's web application storage space. Apart from allowing a malicious user 1 to access or modify private data belonging to user 2, an unintentional security hole in any user's site could also expose all the other users' data. If users are writing or installing their own web apps, I can *guarantee* you'll end up with a Swiss cheese, so containment is critical. If you can give each of your users a sysjail [or virtual machine], bound to its own IP address, then the problem goes away. Each user can simply run their own webserver inside their own file system space. If the users only need to run one-shot CGIs, then you can use cgiwrap or suexec. But those can get very resource intensive, e.g. if every PHP page hit spawns a fresh PHP interpreter and loads in a zillion libraries. With some care you might be able to set up something with fastcgi, at least for serving PHP pages, but adding individual user's apps as different fastcgi processes running as their own UIDs will get awkward if you have to modify a central httpd.conf for each change they request. If the users need to share a single outside IP address, then you can still run a separate webserver for each user, bound to a high port, running as their own UID. But then you need a proxy webserver in front to redirect incoming requests on port 80 to the correct port. Apache mod_proxy does this just fine, but there is some fiddling to do to ensure that the source IP address is still seen as the real outside address (check out mod_extract_forwarded), so that logs and access controls work properly. Personally I think the proxy solution is a good one, as long as you're talking about hosting tens of sites, not tens of thousands, as it gives each user full control over their own web server's configuration (or indeed to run a completely different webserver). Remember that this will result in extra web server processes sitting around consuming RAM. There's also a race risk that when user 1 kills their webserver, user 2 could maliciously bind to user 1's port. In some ways the best solution ultimately is to go with jails, or full VMs. In that case, when user 1 asks you to upgrade mod_fribble from version 0.99a to 1.73b, you can do this confidently (or even let them do it themselves) without any risk of accidentally breaking other users. Disk space is very cheap these days, although RAM and other virtualisation overhead is less so. Regards, Brian.
