Apache 2 + Php 4 + Php 5 + Suphp 0.6.1

[Maniak]

HOW TO : Apache(1&2) + Php 4 + Php 5 + Suphp 0.6.1

Important notice

This tutorial is no longer interesting for Directadmin users; please checkout this http://www.directadmin.com/forum/showthread.php?t=18266

Thanks.

Introduction

This HOW-TO explain you how to setup suPHP 0.6.2 + PHP 4.4.x(CGI) + PHP 5.1.x(CGI).

Including a script that will create a php.ini for each user (existing and new). Just send me a private message.

It works also with Apache 2.2.x

Thanks to d0nuts, we have also solved some problems, it works perfectly.

I ran some successful tests on :

• Fedora Core 3 / 5
• Debian stable
• FreeBSD 6

If you want to try, just feel free. Actually you don't take big risks, because we will not overwrite any file, and we will just handle your php with suPHP, clearly it's pretty safe to try it.

Note

In order to configure and compile PHP5 you will need libxml2 and libxml2-devel. You can install it with all ways, yum, apt-get, ports of FreeBSD and even sources does not matter.

If you need professional support, contact me for further information.

Let's begin

# We download all what we need

[root@mandarine ~]# cd /usr/local/src/
[root@mandarine ~]# wget http://de.php.net/get/php-5.1.4.tar.gz/from/this/mirror
[root@mandarine ~]# wget http://de.php.net/get/php-4.4.2.tar.gz/from/this/mirror
[root@mandarine ~]# wget http://www.suphp.org/download/suphp-0.6.2.tar.gz

# UNTAR/UNZIP ALL

[root@mandarine ~]# tar -zxf php-5.1.4.tar.gz
[root@mandarine ~]# tar -zxf php-4.4.2.tar.gz
[root@mandarine ~]# tar -zxf suphp-0.6.2.tar.gz

# CONFIGURE & COMPILE PHP4

[root@mandarine ~]# cd php-4.4.2
[root@mandarine ~]# ./configure --prefix=/usr/local/php4 --enable-force-cgi-redirect --enable-fastcgi --with-config-file-path=/usr/local/etc/php4/cgi --with-curl --with-curl-dir=/usr/local/lib --with-gd --with-gd-dir=/usr/local/lib --with-gettext --with-jpeg-dir=/usr/local/lib --with-kerberos --with-mcrypt --with-mhash --with-mysql=/usr --with-pear --with-png-dir=/usr/local/lib --with-xml --with-zlib --with-zlib-dir=/usr/local/lib --with-zip --enable-bcmath --enable-calendar --enable-ftp --enable-magic-quotes --enable-sockets --enable-track-vars --enable-mbstring --enable-memory-limit
[root@mandarine ~]# make
[root@mandarine ~]# make install

# CONFIGURE & COMPILE PHP5

[root@mandarine ~]# cd ../php-5.1.4
[root@mandarine ~]# ./configure --prefix=/usr/local/php5 --enable-force-cgi-redirect --enable-fastcgi --with-config-file-path=/usr/local/etc/php5/cgi --with-curl --with-curl-dir=/usr/local/lib --with-gd --with-gd-dir=/usr/local/lib --with-gettext --with-jpeg-dir=/usr/local/lib --with-kerberos --with-mcrypt --with-mhash --with-mysql=/usr --with-pear --with-png-dir=/usr/local/lib --with-xml --with-zlib --with-zlib-dir=/usr/local/lib --with-zip --enable-bcmath --enable-calendar --enable-ftp --enable-magic-quotes --enable-sockets --enable-track-vars --enable-mbstring --enable-memory-limit
[root@mandarine ~]# make
[root@mandarine ~]# make install

# CONFIGURE & COMPILE suPHP

[root@mandarine ~]# cd ../suphp-0.6.2
[root@mandarine ~]# ./configure --prefix=/usr/local/suphp --sysconfdir=/usr/local/suphp/etc/ --with-apache-user=apache --with-setid-mode=owner --with-apxs=/usr/sbin/apxs --disable-checkpath
[root@mandarine ~]# make
[root@mandarine ~]# make install

# PREPARING CLEAN DIRECTORY

[root@mandarine ~]# mkdir -p /usr/local/etc/php4/cgi
[root@mandarine ~]# mkdir -p /usr/local/etc/php5/cgi
[root@mandarine ~]# mkdir -p /usr/local/suphp/etc

# COPYING PHP CONFIG FILES

[root@mandarine ~]# cp /usr/local/src/php-5.1.4/php.ini-dist /usr/local/etc/php5/cgi/php.ini
[root@mandarine ~]# cp /usr/local/src/php-4.4.2/php.ini-dist /usr/local/etc/php4/cgi/php.ini
[root@mandarine ~]# cp /usr/local/src/suphp-0.6.1/doc/suphp.conf-example /usr/local/suphp/etc/suphp.conf

# WE WILL COPY THE FILE WE WILL MODIFICATE...

[root@mandarine ~]# cp /usr/local/suphp/etc/suphp.conf suphp.conf.original
[root@mandarine ~]# cp /etc/httpd/conf/httpd.conf httpd.conf.original

# CREATE THE LOG FILE FOR suPHP

[root@mandarine ~]# touch /var/log/suphp.log

# CONFIGURE suPHP

[root@mandarine ~]# vi /usr/local/suphp/etc/suphp.conf

;User Apache is running as
webserver_user=apache

;Path all scripts have to be in
docroot=/

;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=false

[handlers]
;Handler for php-scripts
x-httpd-php=php:/usr/local/php4/bin/php
x-httpd-php5=php:/usr/local/php5/bin/php

# CONFIGURING HTTPD.CONF

[root@mandarine ~]# vi /etc/httpd/conf/httpd.conf

# After this lines (or at the end of your LoadModule list) :

<IfDefine HAVE_PYTHON>
LoadModule python_module modules/mod_python.so
</IfDefine>

add :

LoadModule suphp_module /usr/lib/apache/mod_suphp.so

then, AND ONLY FOR APACHE 1!

after this lines (or at the end of your AddModule list) :

<IfDefine HAVE_PYTHON>
AddModule mod_python.c
</IfDefine>

add :

AddModule mod_suphp.c

Now again for both...

after AddHandler cgi-script .cgi .pl

add :

AddHandler x-httpd-php .php .inc .php4
AddHandler x-httpd-php5 .php5

and somewhere before your virtualhosts at the bottom

add :

<Location />
suPHP_Engine on
suPHP_ConfigPath /usr/local/etc/php5/cgi/
suPHP_AddHandler x-httpd-php
suPHP_AddHandler x-httpd-php5
</Location>

# TRY IF IT WORKS

[root@mandarine ~]# cd /var/www/html

create two files : test.php and test.php5 with inside :

<?
phpinfo();
?>

[root@mandarine ~]# chown -R apache.apache test.php test.php5

# RESTARTING ALL

[root@mandarine ~]# service httpd restart

go to http://YOURIP/test.php & http://YOURIP/test.php5

--------------------------------------

Now some important remarks

N° 1 : Don't forget to configure your both new php.ini files (/usr/local/etc/php4/cgi/php.ini && /usr/local/etc/php5/cgi/php.ini) - disable_functions etc...

N° 2 : If you get an Error 500 you should try to edit your file /usr/local/suphp/etc/suphp.conf and change :

; Minimum UID
min_uid=0

; Minimum GID
min_gid=0

it's not safe, but at least you will now if the problems comes from the UID/GID.

N° 3 : If you want to run exclusively PHP5 for .php and .php5 :

simply create a .htaccess in the public_html with inside :

AddHandler x-httpd-php5 .php

N° 4 : If you want to forbid one user to run PHP4/5, simply add inside his virtualhost this :

suPHP_Engine off
RemoveHandler .php
RemoveHandler .php5

N° 5 : If you want to offer to one user the possibility to have his own PHP.ini file just add inside his virtualhost this :

<Location />
suPHP_Engine on
suPHP_ConfigPath /home/youruser/domains/yourdomain/public_html/
suPHP_AddHandler x-httpd-php
suPHP_AddHandler x-httpd-php5
</Location>

--------------------------------------

Last update : 21-07-2006

Feedbacks welcome !

 

[d0nut]

works fine! Tested on Debian Sarge and Apache 1.3

Suggestion: Don't remove Loadmodule or AddModule for php4 if you want to use php_admin_flag/value and set
suPHP_UserGroup |USER| |GROUP| into /usr/local/directadmin/data/templates/virtual_* files to apply to all users by control panel.

Bye.

 

[d0nut]

Ideal Configuration for DA

After many test i correct my previous post:

- with this installation with suPHP, Apache not recognize command for php in virtualhost like php_admin_flag and php_admin_value and in .htaccess like php_flag and php_value beacuse with this configuration is implemented for php4 module and not in command line (i not test if is possible to configure php4 in module and php5 by command line using suphp). To solve this problem suPHP allow to create a php.ini for every user (generally in public_html) where users can personalize php functions for theirs spaces.

- the configuration described by Maniak force users to execute scripts inside the public_html directory but Aliases created by DA in httpd.conf for phpMyAdmin / webmail and others don't works because they reside out of public_html directory and is not possible to set suPHP_UserGroup because they are common directory to all users. To solve it, configure suphp with --with-setid-mode=owner and --disable-checkpath

For this configuration remove suPHP_UserGroup in all virtualhosts.

suggestion: see the file suphp.conf in /usr/local/suphp/etc/suphp.conf and set:
- docroot=/
- check_vhost_docroot=false

enjoy

sorry for my english

 

[sspt]

Wow, it works

Thank you very much!

 

[Maniak]

Re: Ideal Configuration for DA

After many test i correct my previous post:

- with this installation with suPHP, Apache not recognize command for php in virtualhost like php_admin_flag and php_admin_value and in .htaccess like php_flag and php_value beacuse with this configuration is implemented for php4 module and not in command line (i not test if is possible to configure php4 in module and php5 by command line using suphp). To solve this problem suPHP allow to create a php.ini for every user (generally in public_html) where users can personalize php functions for theirs spaces.

- the configuration described by Maniak force users to execute scripts inside the public_html directory but Aliases created by DA in httpd.conf for phpMyAdmin / webmail and others don't works because they reside out of public_html directory and is not possible to set suPHP_UserGroup because they are common directory to all users. To solve it, configure suphp with --with-setid-mode=owner and --disable-checkpath

For this configuration remove suPHP_UserGroup in all virtualhosts.

suggestion: see the file suphp.conf in /usr/local/suphp/etc/suphp.conf and set:
- docroot=/
- check_vhost_docroot=false

enjoy

sorry for my english

Hi d0nut,

Right comments.

for security reasons I would avoid let the customers have their own php.ini where they can easily change what's inside.

The best way, is to copy an "ideal" php.ini file in the directory, and chown the php.ini file with the user apache and group apache, in this way, the customer has an own configuration file, and cannot start to rewrite it (as well can't fuc* **) the configuration.

See you

 

[d0nut]

Hi Maniak,

for some customers it could be necessary to set up some parameter of the php.ini for their applications (es. register_globals on in applications as oscommerce that I want to hold of default to off for all the other customers) that same they must be able to modify and whose effects are applied alone on their spaces. It is possible to make this in other way?

Bye

 

[Maniak]

Hi d0nut,

I opened a feature request, because I think it's a main issue and this should concern pretty a lot of people.

Request

 

[Maniak]

d0nut, I was just thinking...

If you let the php.ini editable by customers, you take not some risks, but a real one.

In php.ini you have the security of PHP (which commands are allowed, which path etc...)

Just imagine that the customer has access to the system command, he can handle your server with PHP.

I don't think it's a good idea to do it so. Which risk you take to let the registrer globals to ON?

I think there is nothing to think about...

 

[d0nut]

Hello Maniak, I have already controlled this.
The modifications that a customer carries out on its php.ini in its directory public_html ONLY apply on its space web.
For all the other customers who do not use the php.ini in theirs public_html directory apply the settings of the php.ini general.

 

[Maniak]

Yes I agree, but when you will let a customer to tune his php.ini you will as well let him the ability to run command like "wget" "gcc" "cd" "ls" "uptime" "uname" and with this command the customer can easily handle your server.

In another subject, John wrote me that he's about to check what we did, and he's about to try to include this in the build script.

 

[d0nut]

Even if it is possible to use commands as wget or other is not said that it can have the modification or access rights on the files and directory of other spaces whose allowed they would have to be various for every customer. However if there are innovation or if we want to make of the tests I put my serveur on hand.

 

[Maniak]

Re: Ideal Configuration for DA

After many test i correct my previous post:

To solve this problem suPHP allow to create a php.ini for every user (generally in public_html) where users can personalize php functions for theirs spaces.

Hello d0nut,

Ok, I went on with new tests.

1° - Trying to compile PHP4 or PHP5 as CLI (means not CGI) and handle it with suPHP would give an "error 500".

2° - Using your way :

"./configure --prefix=/usr/local/suphp --sysconfdir=/usr/local/suphp/etc/ --with-apache-user=apache --with-setid-mode=owner --with-apxs=/usr/sbin/apxs --disable-checkpath"

Can you as well forbid some user to use his own php.ini ?

Which directive upper allow user to use his own php.ini ? To let some customer use own php.ini would means also that any customer can decide how many RAM this wants to use for his scripts...

So just let me know which allow the user to use own php.ini.

Thank you.

 

[d0nut]

see this:

http://lists.marsching.biz/pipermail/suphp/2005-August/000985.html

the situation C.

I try but don't have results!

 

[Dualism]

Re: Ideal Configuration for DA

Hello d0nut, I'm Maniak, but I experience some problems with my login, so I created a new account

- with this installation with suPHP, Apache not recognize command for php in virtualhost like php_admin_flag and php_admin_value and in .htaccess like php_flag and php_value beacuse with this configuration is implemented for php4 module and not in command line (i not test if is possible to configure php4 in module and php5 by command line using suphp). To solve this problem suPHP allow to create a php.ini for every user (generally in public_html) where users can personalize php functions for theirs spaces.

I wanted to tell you, I think you're not right; I think you should just give for the default virtualhost user and group apache, and do this :

cd /var/www/webmail
chown -R apache.apache *

same for all scripts located there, you should then even be able to run that scripts from another virtualhost. Simply because I saw on my box that the scripts are owned by root and :

1° - It's unsafe to run that script with root owner.

2° - I think that since the Alias are contained in the gobal httpd.conf and not inside a user specific httpd.conf, the script will run by the virtualhost that call it.

I'm maybe false, but I'm early sure, you don't need to change what I wrote from my howto.

 

[d0nut]

Are 2 problem:

1. DirectAdmin associates the username automatically and the group that comes inserted in the panel and does not use apache:apache.

2. If it does not configure with “--disable-checkpath” suPHP it executes only files with the directives inserted "User" and "Group" indicated in the virtualhost inside the directory in the virtualhost. Therefore if it must execute a Alias that it has path external to this directory gives error because for suPHP the customer of that one directory it does not have the permissions on those path. DirectAdmin set automatically some Alias (webmail / phpmyadmin) for all the users in httpd.conf! The formulation disable-checkpath also from the configuration file can be removed.

These settings have allowed me to use suPHP with the automatic formulations of DA. However there is a problem to resolve: The users can create file php.ini in theirs public_html directory and through it to modify not only the settings listed in PHP_INI_ALL and PHP_INI_PERDIR like in the .htaccess, but also all the other settings. If not wished this, I would advise to use only .htaccess setting up PHP like module.

 

[Dualism]

Hello d0nut,

Ok, but even if I use to repeat it, it is still unsafe to let someone to have access to PHP.INI.

You said yourself that it's unsafe to let customer have his own php.ini, but if the customer decide to create a php.ini file, how can you know that he will not configure something bad about the whole and complete server ?

This means that your way maybe allow to run scripts in alias path, but you will prefer to unsecure your server rather than configure a subdomain alias (like phpmyadmin.domain.com using mod_proxy of apache) ?

Actually, you see, if I understand you :

Good :

- Customer run suPHP for his scripts
- Customer can run script in Alias location (phpmyadmin etc...)

Bad :

- Customer can change the owner of his scripts

E.g. your user is user test group test. This user upload a script called exploit.php. The script is owned by test.test. Then, your customer upload his own php.ini file in the directoy. Since his php.ini allow to use system command he is free to run another php script that will run the following command by example "chown-R root.root exploit.php) (with that second script).

exploit.php will become owned by root.root.

Conclusion :

Where is the security ??

 

[d0nut]

I have tested this creating file exploit.php that make chown root:root on the same file (as described in the post previous) but suPHP it does not allow the change of permissions.

I have tested, in alternative, to print a ls -al of directory of other customers and the command it does not work.

Moreover, even if, in this example, the file became with permission root:root through browser it is not possible to execute it because gives to error 500 since files with those permissions does not belong to the customer test:test

Maniak, if we want, we try some other test in order to control that all it is ok. I attend proposals.

Bye.

 

[Dualism]

Hello d0nut,

thank you for your presence of mind

Ok, so let's tell you :

# ./configure --prefix=/usr/local/suphp --sysconfdir=/usr/local/suphp/etc/ --with-apache-user=apache --with-setid-mode=owner --with-apxs=/usr/sbin/apxs --disable-checkpath
# make
# make install

for me this upper (removing the suPHP_UserGroup user group does not work at all. I also changed the suphp configuration.

I assume that the rest is as my how-to (i as well deleted the directory with suPHP sources).

I can run script inside my directory some scripts but cannot run /phpmyadmin /webmail etc... reason "error 500".

I checked logs, "Premature end of script"...

I'm getting crazy from this.

 

[Dualism]

OK ! I got it.

I deleted the mod_suphp.so file, and recompiled all.

Now it works fine. I had to set min UID=0 and GID=0, actually because /var/www/phpmyadmin is owned by root who has UID/GID 0.



Well, the last question, is, is php.ini file modifiable by customer a good solution ?

I'm going to think about.

 

[Dualism]

Ok ! I got it. I was looking how to forbid user to have his own php.ini and I found.

Here we decide that the global PHP config file is : /usr/local/etc/php5/cgi/php.ini

Simply changing :

<Location />
suPHP_Engine on
suPHP_AddHandler x-httpd-php
suPHP_AddHandler x-httpd-php5
</Location>

to :

<Location />
suPHP_Engine on
suPHP_ConfigPath /usr/local/etc/php5/cgi/
suPHP_AddHandler x-httpd-php
suPHP_AddHandler x-httpd-php5
</Location>

that's it, user can't change it putting a php.ini in public_html.

Oh, and if you need a php.ini for one user, or one virtualhost simply add inside the virtual (not in directory just after the logs stuff) :

<Location />
suPHP_Engine on
suPHP_ConfigPath /home/youruser/domains/yourdomain/public_html/
suPHP_AddHandler x-httpd-php
suPHP_AddHandler x-httpd-php5
</Location>

Oh, and as well sure some of your customers will ask you to run exclusivly PHP5, I mean to have PHP5 for .php and .php5 file, then simply create an .htaccess file with this inside :

AddHandler x-httpd-php5 .php

Conclusion :

User can use both PHP4/5. User can use script in alias path (phpmyadmin), user can if the admin allow it, have an own php.ini file, and all this with a very good standing of security.

So all is great.

I can now only invite the staff to include suPHP in the build script