What I really want to do is allow the 'www-data' user to have the ability to launch php-cgi as another user. I just want to make sure that I fully understand the security implications.

The server should support a shared hosting environment where various (possibly untrusted) users have chroot'ed FTP access to the server to store their HTML and PHP files. Then, since PHP scripts can be malicious and read/write others' files, I'd like to ensure that each users' PHP scripts run with the same user permissions for that user (instead of running as www-data).

Long story short, I have added the following line to my /etc/sudoers file, and I wanted to run it past the community as a sanity check:

www-data ALL = (%www-data) NOPASSWD: /usr/bin/php-cgi

This line should only allow www-data to run a command like this (without a password prompt):

sudo -u some_user /usr/bin/php-cgi

...where some_user is a user in the group www-data. What are the security implications of this?

This should then allow me to modify my Lighttpd configuration like this:

fastcgi.server += ( ".php" =>
        "bin-path" => "sudo -u some_user /usr/bin/php-cgi",
        "socket" => "/tmp/php.socket",
        "max-procs" => 1,
        "bin-environment" => (
            "PHP_FCGI_CHILDREN" => "4",
            "PHP_FCGI_MAX_REQUESTS" => "10000"
        "bin-copy-environment" => (
            "PATH", "SHELL", "USER"
        "broken-scriptfilename" => "enable"

...allowing me to spawn new FastCGI server instances for each user.

  • this is insanity! – RapidWebs Jul 5 '14 at 2:34

I recommend using php-fpm instead (managing all users with one server, but usually not secure if you are using an opcode cache), or spawning the backends with runit and spawn-fcgi.

Then remove the spawn options from the lighttpd config (bin-path, max-procs, bin*-environment)

  • Thanks for the insight! +1 But it didn't quite answer my question. – BMiner Dec 13 '12 at 18:43
  • Hehe, right :) Restricting the sudo to /usr/bin/php-cgi won't help much, as you can just call anything you like with a php script. Otoh the webserver user can tell the FastCGI backend to execute any script it wants anyway, no matter how it was spawned (unless you have further protections in place, base_path perhaps). You just should make sure that the www-data group you used in the sudo spec (and the webuser are in) can't be abused for anything (perhaps use a separate group for it). – Stefan Dec 13 '12 at 23:03
  • As you mentioned, www-data can already execute php-cgi. I guess my question is regarding this line: www-data ALL = (%www-data) NOPASSWD: /usr/bin/php-cgi. Does this only allow www-data to execute php-cgi as any user in the www-data group? If so, I don't think this makes the system any less secure, right? You have to be explicitly added to the www-data group to run php-cgi? Then, once php-cgi is running, you can't "sudo" again, right? – BMiner Dec 14 '12 at 17:57

Apache has an extension which Safely allows the server to change users, before executing a CGI Process. this is called SuEXEC

There is alot of checks, balances, and sanitization that is required, or the wrapper will NOT execute or change user. this is because there is ALOT of things that could go wrong, in turn, jeopardizing the security of your system. I would seriously recommend not doing what you are doing.

I have never run Lighttpd before, simply because with proper tuning, configuration, testing and benchmarking.. It can perform very well.

However, I have found this: it appears to be an implementation of SuEXEC, but for Lighttpd.

Here is some additional documentation on how to use it.

Good Luck.


You appear to be reinventing the wheel (without being aware of the dangers of a faulty wheel)

SuPHP is the answer to your problem and as far as I know it can be made to work with lighttpd.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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