When I first signed up for DreamHost account, I understood, but wasn't overly fond of the way they ran web requests.
All requests to a deployed website on DreamHost are made in the context of the user owning the website. That is, if a website is deployed under user 'X', calls into that website are performed as user 'X'. This allows DreamHost to isolate security breaches to the user of the (defective) website. However, this also has security implications for the individual websites. If there is an exploitable defect within a particular website and a site is compromised, files within that software could be modified as the call is done as the owning user. Setting restrictive permissions (i.e. read-only) on the site's file helps, but doesn't completely mitigate the issue, as the files are owned by the calling user and (in a truly compromised environment) the file permissions could be modified. In a traditional (non shared) web hosting system, this would not be an issue as web-initiated calls would be made by the (highly restricted) user (e.g apache, httpd, etc.) with permission to read (and not write) only those files required to serve the web page.
What follows is the scheme with which I came up to work around this issue. In this discussion, I'll talk about Drupal sites; but the scheme is the same regardless of what files are deployed on a site.
The scheme involves creating two users, the "user" user and the "web" user. The "user" user will own the files comprising the website. Those files will reside in a subdirectory of the "web" user's home directory. These directories and files will be chmod'ed as group readable but not group writable (save those files that will be edited by the website and directories that will be written to.) The "web" user will be the website "run as" user (as defined in the DreamHost domain edit screen). Because the website directories/files were group readable (only), the calling user (the "run-as" user) can read, but not write access to the site's files, and the site functions correctly. The site's files cannot to be modified during a web call. This returns functionality to a semblance of a traditional web scenario.
Note: in this discussion I use the naming convention 'site_user' for the "user" user and 'site_web' for the "web" user where the token 'site' identifies the site or sites being hosted by that user pair. For this scheme to work, the "Enhanced User Security" must be turned off for both users on the user edit screen in the DreamHost panel. Note that this whole scheme works because DreamHost puts all users for the same account on the same physical server. It is also possible to have your primary account be the "user" user rather than creating a new user for this role. If electing this, just replace your primary user's username for 'site_user' in the steps below.
Here are the steps I followed:
To create a new website on this user pair, simply repeat steps 5 and 6 -- create the sites files and then create the domain entry in the DreamHost control panel.
UPDATE1: After this was written, I added an article on setting up a ssh based system for the navigation between accounts.
See the post Shell User Logins
UPDATE2: After this was written, I wrote a script to automate the creation of a user pair. See the setupUserPair.sh script -- a part of my DreamHost script library. It uses 'expect' to automate the logins. It also sets up an automatic ssh path between the "user" user and the "web" user as mentioned in UPDATE1.
Comments
todd
Tue, 02/16/2010 - 17:44
Permalink
The functionality described
The functionality described in this post is now available in the setupUserPair.sh script -- a part of my DreamHost script library.
Anonymous (not verified)
Sun, 11/14/2010 - 21:07
Permalink
why 'user' user
So, why do you want a 'user' user and a 'web' user for every 'domain'? why not recommend using the master user as the 'user' user? I think I'm missing the really good reason to create and manage this many accounts if I'm working by myself. I totally understand the security implications of the way that DreamHost wants to use user accounts and the reason behind setting up a 'web' user. Just not so sold on the extra 'user' user.
todd
Wed, 11/24/2010 - 01:53
Permalink
I suppose you could create a
I suppose you could create a user pair for every domain, but then, with Drupal sites anyway, you'd loose the power that my Drupal script library provides. This power comes from having multiple Drupal sites deployed in the same webroot directory.
I like to create user pairs for logical groups of sites. If for you, a logical group is a group of one, then by all means, make a user pair for every site.
Also, I do have a script available that creates a user pair for you (see UPDATE2, above). See my Dreamhost script library for more information.