Installing SuPHP on Debian Lenny 5.04 with Apache 2.2.9

My daily duties as a sys admin today included installation and configuration of SuPHP .
SuPHP is an apache dynamic module for executing PHP scripts with the permissions of their owners. It consists basicly of twoparts Apache module (mod_suphp) and a setuid root binary (suphp). The suphp module is invoked by the mod_suphp module and instructsApache to change the user id (uid) of the process executing the PHP script.
SuPHP is not a standard Apache module so it’s not 100% tested. Therefore from security point of view it’s better not to use SuPHP.
So beware use it at your own risk! You better know what you’re doing if you’re installing this piece of soft.

The official SuPHP documentation is rather I would say archaic and it’s completely out of date. Though according to the official documentation it’s noted that suphp module won’t work with Apache 2.2.x, it actually works perfectly fine.
I’ve checked and I couldn’t find any tutorials on installing suphp on Debian Lenny therefore I decided to write this tutorial to shed some light on it.
So enough talk let’s approach to the installation and configuration of suphp;

1. Install the module itself from the debian package

debian-server# apt-get install libapache2-mod-suphp
Debian will enable the mod_suphp automatically after installation, though this kind of behaviour is pretty stupid, since it won’t disable mod_php5 which is enabled by default.

2 Therefore we need to disable mod_php5 from executing to enable suphp.

debian-server# a2dismod php5

3. Enable suphp globally for the Apache
Edit /etc/apache2/apache2.conf and put in the end of the configuration file

# Enable SuPHP
suPHP_Engine on
suPHP_AddHandler application/x-httpd-php .php

In my case I’m not using Debian’s default DocumentRoot website location for both my Apache and my VirtualHosts, therefore I need also to configure
suphp.conf

4. Edit /etc/suphp/suphp.conf and change;

;Path all scripts have to be in
docroot=/var/www/

to let’s say:
;Path all scripts have to be in
docroot=/home/

5. Restart your Apache server

debian-server# /etc/init.d/apache2 restart

Now test if mod_suphp is working on your Apache. We will test it through a tiny php script;
Paste the script to let’s say suphp.php

<? system( "id" ); ?>

Now if suphp is working you’ll see something like:
uid=1002(myuser) gid=1002(myuser) groups=1002(myuser)
instead of the default;
uid=33(www-data) gid=33(www-data) groups=32(www-data)

Now there are a few more drawbacks with SuPHP which I feel obliged to discuss.
On the first place suphp will excecute through php5-cgi and therefore the script execution
should be considered a way slower comparing to the default mod_php5.
I cannot precisely tell how much slower would be php script execution compared to mod_php5 but I
pressume at least 10 to 20% of the usual performance will be gone.
One of the possible ways to speed-up php execution in that case is to use mod_fastcgi.

Share this on

Download PDFDownload PDF

25 Responses to “Installing SuPHP on Debian Lenny 5.04 with Apache 2.2.9”

  1. [...] is an apache dynamic module for executing PHP scripts with the permissions of their owners. More here It consists basicly of twoparts Apache module (mod_suphp) and a setuid root binary (suphp). The [...]

  2. Jan Dittberner says:

    I use php5-cgi and mod_fcgid to fullfill the same purpose, maybe you could try this if suphp feels scary/unsupported.

  3. admin Opera Linux says:

    Ok man thanks! I’ll consider it as an option.

  4. [...] is an apache dynamic module for executing PHP scripts with the permissions of their owners. More here It consists basicly of twoparts Apache module (mod_suphp) and a setuid root binary (suphp). The [...]

  5. Kimmo says:

    Correction:
    ————-
    suPHP_AddHandler application/x-httpd-php

    Should be:

    suPHP_AddHandler application/x-httpd-php .php

  6. joni2back says:

    the best manual ever, i tried to do that for long time

  7. Luis Cordova says:

    after following your steps
    now when I go to load my local site ward.local I get to download a file rather than loading it on the browser, wonder what I am doing wrong…

  8. Luis Cordova says:

    here is the apache2.conf file http://gist.github.com/657494
    here is the bunchofsites under /sites-available/bunchofsites http://gist.github.com/657498

    I disabled php5 mod, also now the front page of the site is loading however every other page with a more complex url under a directory is downloading the file rather than interpreting it. So the .htaccess is not working at all. It is not listening to it. hmm

  9. Ian says:

    Thanks for this. The critical step I was missing was #4.

    If you’re using webmin, you can replace #2 and #3 with just disabling php5 and enabling suphp via Configure Apache Modules.

    The test script (just ‘system(‘id’);’ in a php script?) is missing from the article. It must be owned by someone other than root, or suphp won’t touch it (running root scripts destroys the point of the module!)

    • admin Epiphany Debian GNU/Linux says:

      Hi Ian,

      Thanks for the point outs.
      You’re absolutely correct. The php script should contain system(‘id’);. I haven’t noticed that it’s missing in the article. Now I have included it. Thanks for the point outs also for the way to do it easier through webmin.

      Hope to see you around.

      Best

  10. Alex says:

    They are great tips on installing and configuring SuPHP. By the way, is there any advantage of installing SuPHP? I need more help and information before deciding to install and configure SuPHP.

    • admin Epiphany Debian GNU/Linux says:

      If you want files owned by different users to execute with the respective user, and through this tighten security then you will definitely have advantage.

      There is the moment that suphp is external module and it’s not that tested as the rest of apache modules.
      ISo it all depends on your case :)

  11. Maurice says:

    I have a problem with installing suphp on a new server. I’am getting “Internal Server Error” errors.

    The server is running debian 6 with plesk 10.2. We had a lot of problems with running magento on our older servers (debian 4 + plesk 8.6). after some searching and asking around we found out that we need suphp running on the computer system. Searching for installation instructions for suphp we came upon this site.

    I can install suphp like mentioned above without any trouble, but when I try to run the simple php script file I get an internal server error. After checking the suphp.log file I noticed a couple of warnings about right. I fixed those.

    I have no idea what I’m doing wrong. Some pointers would be very welcome.

    • admin Epiphany Debian GNU/Linux says:

      Hi Maurica,
      Check your permissions.
      The “Internal Server Error” common appears in apache error log because of some kind of file or directory permission issues.
      Check that your files are being owned by the user you’re trying to exec the scripts with. Check also that your directories are properly readable by the sued user as well as they have the “+x” flag for the same user. Try to simulate the apache sued scenario with a normal “su – youruser” and see what will happen.
      This might help.

      Another root of the internal server error problems might be because you have some kind of default .htaccess file for the whole webserver or some kind of .htaccess rules for the plesk maybe. If nothing works out try to stop temporary the plesk and see how it goes without it.

      Hope some of my presumed tips will help you.

      Best!
      Georgi

      • Maurice says:

        Hi Georgie,

        Thanks for the reply.

        I got a little further, but still running into problems. If you like you can check the site http://magtest.system4.nl/, http://magtest.system4.nl/suphp.php or http://magtest.system4.nl/test.php. The first is a clean magento install, the second is the default suphp.php test file and the 3th is a default phpinfo().

        The owner of httpdocs is magtest and the group is psaserv. All files under that directory have the same owner en group settings.

        I used the following commands to get all the files of the magento install in line.

        find . -type d -exec chown magtest:psaserv ‘{}’ \;
        find . -type f -exec chown magtest:psaserv ‘{}’ \;
        find . -type d -exec chmod 755 ‘{}’ \;
        find . -type f -exec chmod 644 ‘{}’ \;

        I removed point 3 from the above steps. The config file for suphp is included with the following statement in apache2.conf. The apache2/mods-enabled folder contains symbolic links to the modules in mod-available.

        # Include module configuration:
        Include mods-enabled/*.load
        Include mods-enabled/*.conf

        The apache2/mods-available/mod_suphp.load contains:
        —————————————————————
        LoadModule suphp_module /usr/lib/apache2/modules/mod_suphp.so

        The apache2/mods-available/mod_suphp.conf contains:
        —————————————————————

        AddType application/x-httpd-suphp .php .php3 .php4 .php5 .phtml
        suPHP_AddHandler application/x-httpd-suphp

        AddType application/x-httpd-php .php

        SetHandler x-httpd-php

        suPHP_AddHandler x-httpd-php
        suPHP_AddHandler x-httpd-php5

        suPHP_Engine on

        # By default, disable suPHP for debian packaged web applications as files
        # are owned by root and cannot be executed by suPHP because of min_uid.

        suPHP_Engine off

        # # Use a specific php config file (a dir which contains a php.ini file)
        # suPHP_ConfigPath /etc/php4/cgi/suphp/
        # # Tells mod_suphp NOT to handle requests with the type .
        # suPHP_RemoveHandler

        And my suphp.conf in etc/suphp contains:
        ———————————————–
        [global]
        ;Path to logfile
        logfile=/var/log/suphp/suphp.log

        ;Loglevel
        loglevel=info

        ;User Apache is running as
        webserver_user=www-data

        ;Path all scripts have to be in
        ;docroot=/var/www:${HOME}/public_html
        docroot=/var/www/vhosts:${ HOME}/httpdocs

        ;Path to chroot() to before executing script
        ;chroot=/mychroot

        ; Security options
        allow_file_group_writeable=false
        allow_file_others_writeable=false
        allow_directory_group_writeable=false
        allow_directory_others_writeable=false

        ;Check wheter script is within DOCUMENT_ROOT
        check_vhost_docroot=true

        ;Send minor error messages to browser
        errors_to_browser=true

        ;PATH environment variable
        env_path=/bin:/usr/bin

        ;Umask to set, specify in octal notation
        umask=0033

        ; Minimum UID
        min_uid=100

        ; Minimum GID
        min_gid=100

        [handlers]
        ;Handler for php-scripts
        ;application/x-httpd-suphp=”php:/usr/bin/php-cgi”
        application/x-httpd-php=”php:/usr/local/bin/php-cgi”
        x-httpd-php=”php:/usr/local/bin/php-cgi”

        ;Handler for CGI-scripts
        x-suphp-cgi=”execute:!self”

        You know what I just realized my mistake. my php-cgi bin
        is located in /usr/bin/php-cgi.

        Changed that and I’ve got my first pages working. Although
        I do not see the results from suphp.php script file. The wordpress
        & Magento site do start up and at first glance look good.

        Some things that aren’t clear to me (suphp.conf):
        - umask: what is the propper value for this variable. some sites say 0022, other 0033 and others say 0077
        - headers: what’s the propper text that I should place there ?

        Some things that aren’t clear to me (mod_suphp.conf):
        - Not sure if the addtypes are correct

        • admin Epiphany Debian GNU/Linux says:

          Hi I’m glad you have realized the general problem with fastcgi. With fastcgi it’s always tricky :)
          About the umask, umask sets the default value for permissions of newly created files.
          umask comes from from user file-creation mode mask (umask) is use to determine the file permission for newly created files.
          Most linux distros nowdays has an umask set to 0022. Usually an umask of 0022 should be a good one for you. the umask of 0022 would set file attributes to new files equal to chmod’s 0644 (eg. 0022 is calculated by substracting 0666-022 = 0644, an umask of 0022 would also create your newly created directories under the main directory tree with permissions of 755. If you want to have a really restrictive umask you might set a value of 007. You can further experiment with umask and read about it. There is a plenty of documentation about umasks, just check out ‘man bash’, ‘help umask’ and ‘man chmod’. It’s all quite understandable explained in the mans.
          I cannot get it about headers and mod_suphp.conf?

        • Maurice says:

          those are just the configure file for the suphp module. But no worries. it seems to be working. It seems that magento 1.5 is quite buggy and that is causing a log of trouble for me

          • admin Epiphany Debian GNU/Linux says:

            I’m glad you make it sorry, too bad magento is buggy. But you know, you never get guarantees with free software :)
            Hope to be seeing you around.

            Wish you best!
            Georgi

        • Maurice says:

          Take care, and thanks you for the help ;)

  12. Mike says:

    Fairly insighful post.Never believed that it was simple after all.I had spent a beneficial deal of my time looking for someone to explain this subject clearly and you’re the only one that ever did that.Keep it up.

Leave a Reply