Posted by Administrator on 24 December 2009 10:48 PM
Our new servers have PHPsuexec enabled for better security for our customers.
When PHP runs as an Apache Module it executes as the user/group of the webserver which is usually "nobody". Under this mode, files or directories that require your php scripts to write to need to have 777 permissions (read/write/execute at user/group/world level). This is not very secure because besides allowing the webserver to write to the file it also allows anyone else to read or write to the file.
With PHP running as CGI with suexec enabled your php scripts now execute under your user/group level. Files or directories that require your php scripts to write to no longer need to have 777 permissions. In fact, having 777 permissions on your scripts or the directories they reside in will not run and will instead cause a 500 internal server error when attempting to execute them to protect you from someone abusing your scripts. Your scripts and directories can have a maximum of 755 permissions (read/write/execute by you, read/execute by everyone else). PHP running as CGI/suexec is much more secure than the older Apache module method.
Files and directories also need to be owned by your user/group. You probably don't need to worry about this as all files you upload or create will be owned by your user/group automatically.
As most of you already know, PHP Files are not meant to be read, but parsed, and that is where the problem resides. PHP Files have to be parsed, otherwise everyone who is able to read your php file will see settings that you would probably want to keep private, such as your MySQL username and password.
PHPSUEXEC fixes all this because it requires php to be run as the file owner's username. (for example: andre)
This is not everything it fixes though. PHPSUEXEC is also here to fix file ownership problems. This has been a common issue on a few Content Management Systems such as Joomla and also on the popular blog software: WordPress.
It also adds security to your files as you can use permissions such as 600 or 700 in your files and your visitors will still be able to view them (parsed) in their browsers.
PHPSUEXEC will also refuse to serve any pages that are at security risk, for example with 777 as permissions. (will generate an Internal Server Error)
Under the old Apache Module mode you were able to manipulate the PHP settings from within a .htaccess file placed in the script's directory.
For example you could turn off the php setting "magic_quotes_gpc" with this line in .htaccess:
php_value magic_quotes_gpc on
With PHP running as CGI/phpsuexec manipulating the PHP settings is still possible however it can not be done with .htaccess. Using .htaccess with php_value entries within it will cause a 500 internal server error when attempting to access the scripts. This is because php is no longer running as an apache module and apache will not handle those directives any longer.
All php values should be removed from your .htaccess files to avoid the 500 internal server error. Creating a php.ini file to manipulate the php settings will solve this issue.
What is a php.ini file and how do I go about making one
The php.ini file is a configuration file that the server looks at to see what options have been turned on, off or set to a number different from the defaults that we have set for the server. While the name may seem advanced to those unfamiliar with it, it's simply a text file with the name php.ini
To create a php.ini file, just open up a text editor, add in the lines you need and save the file. You can name the file whatever you wish when saving. Once done, upload the file to the directory where your script is located and then rename it to php.ini
For example you can turn off the php setting "magic_quotes_gpc" with this line in php.ini:
magic_quotes_gpc = no
All the php_flags in your .htaccess will have to be moved to php.ini, which you will have to create in your public_html directory.
.htaccess Â» php_flag register_globals on
php.ini Â» register_globals=on
The file php.ini will handle all the extra settings you need to set in php.
So, basically you will have to move every command on .htaccess that starts with php_flag.
Troubleshooting Internal Server Errors (Error 500)
Everytime an internal server error occurs, it will be added to your Error Log in cPanel. (cPanel Â»Â» Error Log). This will usually give you a clue on where the error resides. In most cases it will be either a permission error on a bad command in your .htaccess file (remember that all php values have to go to your php.ini file).
Directories that need to be written onto will no longer require 777 as permissions and phpsuexec will refuse to write or read on directories exposed with such permissions. You will have to chmod them to 755 always.
To simplify it, just remember that you should never have a file or folder with world-writeable permissions, because you no longer have to.
1. Check that the php script that you are attempting to execute has permissions of no more than 755 - 644 will work just fine normally, this is not something that will need to be changed in most cases.
2. Check that the directory permissions that the script resides within is set to a maximum of 755. This also includes directories that the script would need to have access to also.
3. Check that you do not have a .htaccess file with php_values within it. They will cause a 500 Internal server error, when attempting to execute the script.
The php_values will need to be removed from your .htaccess file and a php.ini put in its place, containing the php directives as explained above.
If you added a Mimetype to the system in order to run html files as php scripts (AddType as .htaccess command), you will have to remove it and add an ApacheHandler instead. This is easy to do though. Just log into your control panel, then click on Apache Handlers and add the following:
Extension: html (or htm)
Technically, PHPSUEXEC will make sure your scripts and directories abide by the following security rules:
* User executing the wrapper must be a valid user on the server.
* The command that the request wishes to execute must not contain a /.
* The command being executed must reside under the user's web document root (public_html).
* The current working directory must be a directory.
* The current working directory must not be writeable by group or other.
* The command being executed cannot be a symbolic link.
* The command being executed cannot be writeable by group or other.
* The command being executed cannot be a setuid or setgid program.
* The target UID and GID must be a valid user and group on the system.
* The target UID and GID to execute as, must match the UID and GID of the directory.
* The target execution UID and GID must not be the privileged ID 0.
* Group access list is set to NOGROUP and the command is executed.