XILO Community Forum

**Matt**

Dear Reseller Customers,

Over the last few months, we have been evaluating PHPsuexec which has many security benefits.

Currently, when a PHP script is called via your web browser it is executed by the webserver user nobody and not the user account where the script actually resides.

This is also a problem for many content management systems such as Mambo/Joomla! and also some gallery software such as "gallery" and coppermine as the files are written by the "nobody" user which can then not be edited or removed via your normal FTP account. (We do receive many tickets regarding this issue; asking us to delete files).

What changes may need to be made on your site.
If you use any php_flag directives in a .htaccess file, you will need to move these into a file named php.ini to allow the override to work correctly.

The directive we see used the most is register_globals. Below, we will detail the change needed for any site requiring this to be on.

In your .htaccess file you would have listed;
php_flag register_globals on

This would then be replaced with the following in php.ini;
register_globals=on

Possible Error Messages
Internal Server Error 500 is generally caused by files with permissions that are set incorrectly.

As the owner is running the script instead of the web server user, folders with 777 permissions are no longer permitted and will cause this error to occur. Setting to 755 should resolve the issue.

The maximum permissions you can assign to a file under PHPsuexec are 644 and for folders is 755.

Inline with this upgrade, register_globals will be disabled globally to also help with security. This is already the case on a number of servers but for those sites that require this function to be on, please follow the above instructions on creating a php.ini file to set this.

We plan to start these upgrades in the following order of servers to start with.

kilo - 14th May 2006 - Complete
asteroid - 14th May 2006 - Complete
delta - 17th May 2006 - Complete
alpha - 30th May 2006 - Complete
bravo - 31st May 2006 - Complete
foxtrot - 4th June 2006 - Complete
charlie - 4th June 2006 - Complete

We have a number of scripts that will fix most common problems, however, there is always the chance that we may miss one or two less standard sites.

The first change will take place in the early hours of this weekend (sunday) on the kilo server only.

Please use this thread if you have any questions regarding the technical aspects of your site or for any further information.

---
Added after initial post.

Zend
If you need to have Zend Optimizer support, you should add the following to php.ini if you have any problems with it not showing the encrypted files.

Code:

[Zend]
zend_optimizer.optimization_level=15
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.0.0
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.0.0
zend_optimizer.version=3.0.0


zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so

**arrivist**

Can you clear up a couple of points?

1. Are you going to update the permissions for php files/folders when you install the PHPsuexec software or do we need to do it?

2. Is there any way we can test a php.ini before the switchover? I have had problems with php session files being created as 'nobody' so I have set up a custom session handler that uses mysql to store my session data. Obviously I need to make sure the transition is seamless otherwise I may lose session info, and consequently custom.

3. Do you know if you can use the php.ini files in a hierarchical manner as you can with .htaccess. For example, I set the following flags in my root .htaccess file:
>> php_flag display_errors off
>> php_value error_reporting 7

If I have problems with a script in a subdirectory, I just add a .htaccess file to the subdirectory with:
>> php_flag display_errors on
and I get full error reporting in that directory ONLY. It is very useful to be able to affect php functionality on a directory by directory basis.

4. Most developers do not use PHPsuexec when creating packages, and consequently any php packages we install from external sources may have incompatible permissions. From my understanding, PHPsuexec will REFUSE to run any scripts that are world writable, and this may cause problems for the uninitiated when external packages are installed. Are you going to provide any tools to 'correct' the permissions so that they are compatible with the PHPsuexec software?

5. Lastly, do you send out emails warning of such changes? (I can't find any mention of a mailing list in my account settings). I only happened across this news because I was browsing the forums, however had I not spotted it this change could have caused real problems with my sites. May I suggest that if you do not have a newsletter in place, that you consider creating one. I for one would prefer to be contacted and pre-warned of such changes.

Sorry for the rant

....
Richard

**Kieran**

I have been on a server with PHPsuexec on it before and quite like it so am in favour of the change - there is nothing more annoying that not being able to delete a file in your own space because it was written by php. As the changes will make php run as the user, will this mean files previously created by php will now not be writable by php again? If so, can it be arranged to chown everything currently owned by nobody in public_html to the user?

That aside, can we have precise dates/times for the installation of PHPsuexec on each server? I ask because changing to 755 on directories that need to be writable early will cause CMS/upload scripts to fail, and likewise doing it too late will cause failures/500 errors. Neither of which is desirable, especially for busy sites.

Thanks

**Tom**

Quote: