This site is now 100% read-only, and retired.

Running PHP scripts as specific users with suphp

Posted by Steve on Tue 25 Jan 2005 at 11:33

If you run a webserver for lots of different users it can be useful to allow all the PHP scripts to run under the identity of the user who owns them - rather than having all PHP scripts upon the system run as the same user (Typically www-data on Debian systems). suphp allows you to do this easily.

The module wasn't packaged as part of the Debian Woody release so we'll only mention using Sid / Testing here.

If you wish to install the module on a Woody system you will have to investigate a backported version, or build it from source yourself (which isn't as hard as it sounds!).

If you're running Debian testing (sarge), or sid you can install the module as follows:

apt-get install libapache-mod-suphp

This will install the cli version of PHP, that that is the version which can be executed from the command line. This is invoked by the Apache module when incoming requests are made to PHP scripts.

Now that we've installed the module we need to set it up, there are two things to do:

  • Remove the mention of mod-php.
  • Configure suphp.

Removing the module version of php can be done by commenting out these lines in your Apache configuration files /etc/apache/httpd.conf, and /etc/apache/modules.conf:

LoadModule php4_module /usr/lib/apache/1.3/
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

Once those lines are commented out, or removed, you can remove the libapache-mod-php packge:

dpkg --purge libapache-mod-php4

You might have installed a virtual package php4, if so you will recieved errors and should remove that package too:

dpkg --purge libapache-mod-php4 php4

Now we need to configure the suphp module. First of all we need to make sure it is loaded, by including the following line in /etc/apache/modules.conf:

Loadmodule suphp_module /usr/lib/apache/1.3/

Then in the main configuration file we need to add the following three directives, after the loading of the modules:

suPHP_Engine on
suPHP_ConfigPath /etc/php4/apache
AddHandler x-httpd-php .php

This should be sufficient to allow the module to work. Restart apache and see if you recieve any errors if not your setup is complete.

Now because your PHP scripts will be running under different user IDs than before you might need to make some changes to them - for example if you had a script which used to write to its own data files them might be owned by www-data, or nobody. These should now be changed to the user id the script is owned by, and is running as.

Notes the way the module works is to look at the owner of the script, and then become that user to execute it, but it will refuse to execute scripts owned by root. You should instead add a user to own those files.

To test the module we can write a simple file:

cat >> /var/www/t.php << EOF
<? system( "id" ); ?>
chown steve:steve /var/www/t.php

Executing that by calling it from a client will show you something similar to this output:

uid=1000(steve) gid=1000(steve) groups=1000(steve)



Re: Running PHP scripts as specific users with sup
Posted by Anonymous (128.214.xx.xx) on Tue 8 Feb 2005 at 17:01
Another possibility is to use suexec and fastcgi version of php, but this requires a bit of configuration and self-compiled binaries.

Example server configuration, with less than signs changed to (

(IfModule mod_fastcgi.c>
(LocationMatch "^/~.*/fcgi/">
Options ExecCGI
SetHandler fastcgi-script

In user .htaccess:

AddHandler php-fastcgi .php
Action php-fastcgi /~username/fcgi/php

php binary needs to be ./configured with --enable-fastcgi.

Viljo Viitanen (Viljo.Viitanen AT helsinki dot fi)

[ Parent ]

Re: Running PHP scripts as specific users with sup
Posted by jeffw (203.24.xx.xx) on Mon 4 Sep 2006 at 06:15
The php4-cgi packages in sarge should already support fastcgi:

$ /usr/lib/cgi-bin/php4 -v
PHP 4.3.10-16 (cgi-fcgi) (built: Aug 24 2005 20:08:55)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
with Zend Extension Manager v1.0.10, Copyright (c) 2003-2006, by Zend Technologies
with Zend Optimizer v3.0.1, Copyright (c) 1998-2006, by Zend Technologies

Note the cgi-fcgi bit.


[ Parent ]

Re: Running PHP scripts as specific users with suphp
Posted by Anonymous (83.145.xx.xx) on Thu 28 Jul 2005 at 14:59
I wrote an article on the same subject on my blog (fr), this talk about suexec mode of Apache ...

Maybe this can be an other solution for this kind of configuration ... gi-mode-suexec

hope this can help you

[ Parent ]

suphp and mod_userdir
Posted by niol (143.196.xx.xx) on Wed 5 Oct 2005 at 13:21
[ View Weblogs ]

suphp and mod_userdir don't play well together because the user public html directory is often outside de document root, and suphp kind of chroots the php scripts to the document root.

The problem occurs in the sarge suphp version. The etch version is a total rewrite in C++ and I don't know if the problem exists anymore. There are several options :

  • quit using mod_userdir and emulate it using symlinks. This is a pain if you have multiple users, but scriptable. This is easy if you have only a few users.
  • some people on a mailling list (sorry, cannot remember the link) suggested using redirections to a virtual host for each user. This is easy, but if you do not want multiple virtual hosts for your user, that's not good.
  • recompile suphp with the --disable-checkpath option. This turns of the feature of suphp. This is a bit less secure, but the point of using suphp is to turn PHP Safe mode On, and with safe mode, a user's php scripts cannot access files owned by a different user. Compiling is not that hard, I used a sarge chroot with build-essentials installed.

apt-build got me Ruby errors because of a known bug. So I recompiled manually. The process to recompile suphp and at the same time keep a clean sarge for the server was about like the following. That's my first package recompile, so details may not be accurate, but it worked!

# aptitude install debootstrap
# debootstrap stable /var/chroots/sarge
# chroot /var/chroots/stable
# apt-setup
# cd /usr/src
# apt-get source suphp
# apt-get build-dep suphp
Then I patched debian/rules to use the --disable-checkpath option :
--- suphp-0.5.2/debian/rules0.5.2005-10-05 12:11:58.855690176 +0000
+++ suphp-0.5.2-nocheckpath1/debian/rules       2005-10-05 12:14:05.530432688 +0000
@@ -28,6 +28,7 @@
        --with-apache-user=www-data \
        --with-php=/usr/lib/cgi-bin/php4 \
        --sbindir=/usr/lib/suphp \
+       --disable-checkpath \

@@ -37,6 +38,7 @@
        --with-apache-user=www-data \
        --with-php=/usr/lib/cgi-bin/php4 \
        --sbindir=/usr/lib/suphp \
+       --disable-checkpath \

Then I ran dhc to update the changelog and the version that I called 0.5.2-3-nocheckpath1. And dhbuild produced the expected debian packages that I installed on my sarge system.

[ Parent ]

Re: suphp and mod_userdir
Posted by Anonymous (81.221.xx.xx) on Fri 27 Apr 2007 at 21:24
Well, I fiddled quite a long time until I halfways understood the topic of the document root. In fact, instead of recompiling the binary with --disable-checkpath you can also edit the config file


where you can set




I don't recommend this on a server where security is a big issue, but for my little server at an educational institution, this is good enough.


I. Blochliger

[ Parent ]