Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a problem to which I already have an implemented solution, but I'm not sure whether it's the best one. In the interests of not biasing any possible responses, I won't say how I've chosen to solve it yet.

Let's say I have a website with different users.

Each of these users has a collection of server-side files.

I'd like each user to be able to run an untrusted serverside binary application. This binary application needs to work with the users' serverside files.

By untrusted I mean, let us assume it's 'bash' - completely open to exploitation. I'd like to ensure that primarily:

  1. Each user can only access their own files from this untrusted app
  2. Each user cannot affect the operation or security of the overall system from this untrusted app
  3. The solution can reasonably scale to many thousands of users

My question is: how would you provide this?

share|improve this question
up vote 2 down vote accepted

suPHP as a wrapper to cause CGI execution of the app in the user's context; you also gain a bunch of nice instrumentation and environment configuration into the bargain. We have scaled this above ten thousand unique users.

share|improve this answer
Thanks Jeff, however this does require that the php scripts being executed are owned by the user in question, does it not? I guess that is normal for a webhosting environment, but my use case is more of a webapp. Interesting though. Cant vote answers up - don't have enough points! – dan Feb 4 '11 at 18:29
We run a custom suPHP wrapper script (it's actually completely CGI-general, so not just for PHP) that lets us make runtime decisions about who to execute as, regardless of executable file ownership. You take a bit of an overhead hit to run the wrapper on every request, but it hasn't posed a major headache for us - we just scale to more front-end nodes. – Jeff Albert Feb 4 '11 at 18:55
Jeff - care to elaborate a bit on how your suphp wrapper works? What is it wrapping exactly - the suphp setuid binary i take it? – dan Feb 15 '11 at 15:37
The way we run it, suPHP invokes a custom wrapper script of our design which sets up an environment for an interpreter: php_cli, perl, bash, whatever, as defined by the interpreter line of the script being executed - and setuids to, by default, the user which owns the file being executed. All of that stuff, including who to setuid to, is configurable in the wrapper. We also use it to enable stuff like custom per-script php.ini and interpreter versions. – Jeff Albert Feb 15 '11 at 17:44

Run a virtual host for each user and suexec to a cgi application that runs in a chroot wrapper

See here for a tutorial, for example..

share|improve this answer
Thanks for the answer Mike, though I have just edited the question to clarify that the solution must scale to thousands of users. Not sure if thousands of virtualhosts would be quite right. Plus the CGI would not be owned by the user. But point taken that the canonical way to do this is suexec. – dan Feb 4 '11 at 17:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.