I am part of a team of volunteers providing a hosting platform for Linux User Groups in the UK. As part of this service, we are setting up a "static and managed" (S&M) server, from which people can either host static web content, or use pre-installed webapps which we provide, such as MediaWiki. This will allow us to manage the software versions, security patches and upgrades across all hosted sites, without having to rely on the individual owners of the sites to perform security upgrades in a timely fashion (which doesn't happen in many cases).

One requirement of this system, therefore, is that the users (i.e. administrators of each website) don't have a direct login to the machine, and that they can't run arbitrary code on it. This means that we've made it impossible to execute PHP directly from their upload space.

In investigating fitting a multisite-mode Drupal into this environment, I've found a few major issues for us so far, and would appreciate any advice on how best to go about dealing with them in the above environment.

1) Themes.

From my limited investigation so far, it seems that Drupal themes are basically PHP. Allowing users to upload themes directly is therefore a no-no. Is there a non-executable type of theme that we can support direct uploads for safely, or will all uploaded themes have to be audited before we allow them up? How flexible would the system be if we were to prevent theme uploads completely?

2) Input filters.

In admin/settings/filters, there's a "PHP Code" filter, which seems to give the option of allowing the administrator to execute arbitrary PHP on the server. Is there any easy way of turning this off without losing the filter module entirely? Are there any usability implications of doing so?

3) Uploads.

Is there adequate separation between sites' upload areas? I see in admin/settings/file-system that there is a path for uploaded files. What is there to prevent someone from pointing that path at another site's upload directory and fiddling with their files?

4) What else have I forgotten or overlooked?

The chances of having a malicious user are probably fairly small in this set-up, but I'd like to keep it as "clean" as possible, so pointing out any other glaring holes that would allow a site administrator to execute arbitrary code on the server would be useful.

Thanks for getting this far, Hugo.