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.