Php – Running mod_php and suPHP same time

mod-phpPHPphp5php53suphp

I recently went from Debian Lenny with 5.2.x and was able to use mod_php for any php files that were not located in /home/ and suPHP for all the php files that were located in /home/.

I did this because I needed a default php.ini (given me all features of php) for my websites in /var/www/ and I didn't want to have to change the owner of all the .php files from root. I also had a default php.ini for all the /home/ php files without dangerous features.

This was I had setup:

    <IfModule mod_suphp.c>
        <Directory /home/>
                AddType application/x-httpd-php .php .php3 .php4 .php5
                suPHP_AddHandler application/x-httpd-php
                suPHP_Engine on

                suPHP_ConfigPath /home/shared/
        </Directory>
    </IfModule>

This was working perfect, but recently I upgraded to PHP to 5.3.5 from dotdeb (Lenny has no official php 5.3) . This had weird issues on lenny such as not display errors correctly and little tid bits. So I decided to upgrade from lenny to squeeze. Uninstalled php (along with it came suphp) and reinstalled with the new source. I now have 5.3.3-7 with Debian Squeeze but I cannot get mod_php and suPHP to run at the same time anymore. mod_php will always work and there are no errors in apache2 or suphp logs. If I disabled mod_php then suPHP will work.

Is there thing I am doing wrong?

Best Answer

I was able to accomplish what I was after by putting php_admin_flag engine Off at the top of the mod_suphp.c. Also I had to make sure I used suPHP_Engine off by default.

End result:

    <IfModule mod_suphp.c>
        <Directory /home/>
                php_admin_flag engine Off
                AddType application/x-httpd-php .php .php3 .php4 .php5
                suPHP_AddHandler application/x-httpd-php
                suPHP_Engine on

                suPHP_ConfigPath /home/shared/
        </Directory>
    </IfModule>

Just for those wondering, this is what I had for my /home/shared/php.ini they will be every /home users php.ini unless I specify differently in vhosts:

allow_url_fopen = Off 
display_errors = On 
display_startup_errors = On 
log_errors = On 
error_reporting = E_ALL 
error_log = "/var/log/apache2/php_user_errors.log"
expose_php = Off 
magic_quotes_sybase = Off 
register_globals = Off
open_basedir = "/home:/tmp"
short_open_tag = On
session.save_path = "/tmp"
disable_functions = "phpinfo, apache_child_terminate,apache_get_modules,apache_get_version,apache_getenv,apache_note,apache_setenv,curl_exec,curl_multi_exec,dir,disk_free_space,diskfreespace,dl,eval,exec,fsockopen,highlight_file,ini_alter,ini_restore,ini_set,openlog,parse_ini_file,passthru,pclose,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,readfile,set_time_limit,shell_exec,show_source,stream_socket_server,symlink,system,virtual"

Related Solutions

Linux – PHP not being parsed in apache2, php module is installed and enabled

When I do the same grep of my config files, I get one line you didn't:

/etc/apache2/mods-enabled/dir.conf:3:          DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm

Make sure this line in /etc/php5/apache2/php.ini is set this way:

; Enable the PHP scripting language engine under Apache.
engine = On

If you change it, restart Apache:

sudo apache2ctl restart

Php writing deprecated errors to apache error log

While the other answers here will stop the errors being written to your error log, they are simply ignoring the the error message and not fixing the error.

The error in this case is that your php.ini still has either magic_quotes_gpc on or magic_quotes_gpc off somewhere in it. The same is true for register_globals on or register_globals off.

The error is not that the directive is on or off. The error is that the directive shouldn't exist at all. Comment those lines out of your php.ini or remove them entirely and PHP will stop writing errors about deprecated directives.

Of course, this may cause problems with your application if it requires either of those to be on.

The reason this is an error in PHP 5.3 is that in PHP 6, these directives won't even exist and PHP 6 will behave as if they were set to off. If you ever plan on upgrading to PHP 6, now is a good time to start upgrading or replacing your application.

Another solution you could try is downgrading PHP back to the 5.2 or 5.1 branch.

As for PHP writing errors into Apache's log, this is natural because PHP is running as an Apache module. You can put something like error_log = /var/log/php_errors.log into your php.ini and restart Apache to have the PHP errors separated from your Apache errors. While you're in there, I would recommend changing display_errors to off. Error messages can often contain sensitive information that you wouldn't want an attacker to see. You will most likely see this written in your php.ini:

; - display_errors = Off           [Security]
;     With this directive set to off, errors that occur during the execution of
;     scripts will no longer be displayed as a part of the script output, and thus,
;     will no longer be exposed to remote users.  With some errors, the error message
;     content may expose information about your script, web server, or database
;     server that may be exploitable for hacking.  Production sites should have this
;     directive set to off.

There is no sane reason why the error messages contain HTML.

To answer another question that you didn't ask, the reason PHP reports this as being in <b>Unknown</b> on line <b>0</b> is that the error message was designed for lines of PHP code that you have written but the error it found was in parsing the php.ini before it has even read a single line of code or even opened a .php file. Since it hasn't opened a file and doesn't have a line number, it reports them as "Unknown" and "0".

Best Answer

Related Solutions

Linux – PHP not being parsed in apache2, php module is installed and enabled

Php writing deprecated errors to apache error log

Related Topic