What is PHPSuexec?

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

PHPSuexec is the shortened term often used to describe running PHP as a CGI with Suexec. Running PHP as a CGI with Suexec creates a much more secure environment compared to running PHP as an Apache module. Below we will describe the differences in the two forms of PHP, with examples on how security differs with the two.

PHP as an Apache Module
When PHP runs as an Apache module, PHP files work under the Apache user/group known as "nobody". For example, when a PHP file needs to write to another file or create/remove a file, it does so under the name "nobody". In order to allow "nobody" to do this, you need to set specific permissions on the file/directory, such as 777 - which translates to read/write/execute by user/group/world. This is insecure because you have not only allowed the webserver (Apache) to read/write to the file, you have also allowed everyone else on the server to read/write to the file as well!

Due to the above conditions, when a PHP file creates or uploads a new file under your account, the new file will be owned by the user "nobody". If you FTP into your account, all files owned by "nobody" will not be available for you to move, rename or delete. In this case the only way to remove the "nobody" owned files would be through a file on the server or to contact support and ask for the file ownership to be changed back to your username.

PHP as a CGI with Suexec
When PHP runs as a CGI with Suexec, PHP files work under your user/group. PHP files no longer require loose permissions to function, now they will require strict permissions. Setting your directories or PHP files to 777 will cause them to produce a 500 Internal Server Error, this happens to protect your PHP files from being abused by outside sources.

Under PHPSuexec your directories and PHP files can have permissions no greater than 755 (read/write/execute by your username, read/execute by group/world). Since you own your files, your scripts can function in any directory your user has created and can't be manipulated by any outside users, including "nobody".

Now, when a PHP file creates or uploads a new file under your account, the new file will be owned by your username. You will no longer have to worry about the webserver taking over your files and even more important you will no longer have to worry about a stranger writing to your folders/files, and, depending on your permissions (of course), you will no longer have to worry about a stranger reading your files if you don't want/need them to.

.htaccess
When PHP runs as an Apache module you are able to manipulate PHP using .htaccess - since .htaccess is an Apache feature. When PHP runs as a CGI, you can no longer do this because Apache no longer understand the PHP flags and values. Instead, when PHP runs as a CGI, you will need to create your own PHP initialization file, this file is called php.ini -- php.ini works almost the same as .htaccess -- it is simply a text file with directives that will be used instead of the servers default directives.

To give you a better understanding about how both work in regards to PHP, we have listed a .htaccess file and a php.ini file below.

.htaccess
php_value magic_quotes_gpc on

php.ini
magic_quotes_gpc = on

There is one main difference to the use of .htaccess vs php.ini -- a .htaccess file can be placed at the root directory and affect all subdirectories with just 1 file, php.ini does not work this way. A php.ini file needs to be placed in every directory and subdirectory that requires the altered directives. This is a downfall for using PHPSuexec, however we hope that in the future PHP can be written to handle the php.ini file in a more workable fashion.

Last but not least, there is a directive used in .htaccess that needs to be altered in order to work under PHPSuexec. The directive ForceType needs to be changed to SetHandler. For example:

PHP as an Apache Module .htaccess Style
<Files directory>
ForceType application/x-httpd-php
</Files>

PHP as a CGI with Suexec .htaccess Style
<Files directory>
SetHandler application/x-httpd-php
</Files>

It is important to understand that you can still use .htaccess for a variety of Apache functions, such as mod_rewrite directives, password protection directives, etc. The only difference is that it can no longer process PHP directives.

Common Problems experienced with PHPSuexec
If your PHP scripts are reporting 500 Internal Server errors, please check the following:

* Make sure the directory permissions the PHP file is in are no greater than 755

* Make sure the PHP file permissions are no greater than 755 - 644 is the default permissions for files uploaded by FTP and will work fine for most PHP files.

* Make sure you do not have any .htaccess files which contain PHP flags/values or ForceType directives. These directives need to be handled differently, as explained above.

registered · Posted: Tue Nov 27, 2007 5:30 am

For folks using the HTML Newsletter, which needed 777 in order to write to its newsletter archive directory, what this means is that once the conversion to PHPSuExec happens, you will have to change the permissions on that directory to 755. You will also need to have the ownership of the files within that directory to be changed to your user account in order for the tool to properly manage these files (such as when you want to delete a newsletter). In addition, the temporary files that are created for the Preview and Test Email send should either have their permissions changed as previously stated OR they can just be deleted (as long as you are not in the process of writing / reviewing a newsletter).

Posted: Tue Nov 27, 2007 7:16 am

Thanks Montego.

Just as an FYI (for any/all scripts/applications) the ownership of the files are automatically changed to user_account:user_account. The 755 should in no way affect the operation of your various scripts unless the script was specifically written to check for 777/666 and fail an operation if not found. Even then it's just a matter of modifying what the limits are for installation.

Posted: Tue Nov 27, 2007 7:36 am

I think I understand this from a previous email but just to confirm. During conversion any directories or files that are currently 777 will be changed to 755 without intervention by the user? Also will ownership be changed automatically or do we need to do it?

I have also noticed in the past that the chown command from a FTP client doesn't work for Gallery files, but I am now assuming that was because the client didn't own the files (they were owned by nobody). There probably should be no need for the command under phpsuexec. (For a user).

Posted: Tue Nov 27, 2007 8:33 am

fkelly wrote:

During conversion any directories or files that are currently 777 will be changed to 755 without intervention by the user?

Permissions will NOT be automatically changed. However, I found/developed (can't remember which Laughing

) and enhanced a script that root access users can run. I will make myself available to run this but on a per request basis. Some installations may want to use something other than 755. Nothing comes to mind but I don't want to blanket change permissions. For those interested, here is the little diddy Smile

Code:

find $DIR -type f -print0 | xargs -0 chmod $FILEMODES


find $DIR -type d -print0 | xargs -0 chmod $DIRMODES





# Using "xargs" allows for very large directory trees.  As xargs will fork() the command every time it reaches max argv size.





__Examples:__


find public_html -type d -print0 | xargs -0 chmod 755


find public_html -type f -print0 | xargs -0 chmod 644

fkelly wrote:

Also will ownership be changed automatically or do we need to do it?

Ownership will be changed automatically (in most cases). Apparently there may be some anomalies that occasionally pop up but they should be easily fixed.

fkelly wrote:

I have also noticed in the past that the chown command from a FTP client doesn't work for Gallery files, but I am now assuming that was because the client didn't own the files (they were owned by nobody). There probably should be no need for the command under phpsuexec. (For a user).

That is my understanding but you should check with the Gallery developers.

Posted: Tue Nov 27, 2007 9:14 am

Looking further, just at my "production" site, I see that the entire Gallery data directory, which contains hundreds, if not thousands of subdirectories is 777. I was originally thinking, "so what" ... Gallery might not work right after the conversion but we could fix it in the day or two after by adjusting permissions. But then I was thinking, I have a random image block on my home page that accesses Gallery. So everyone who uses the site will probably be seeing the 500 error as soon as the conversion is done.

The ownership of the directory does appear to be my web server user, not "nobody" so that should be okay unless somewhere down in the directory hierarchy a subdirectory got created under nobody. But I think a recursive chmod is going to need to be run on the whole data directory and coordinated in terms of timing with the conversion.

Here is a link to Gallery documentation relevant to this topic.

Only registered users can see links on this board! Get registered or login!

They heartily endorse PHPsuexec and seem to be saying we could get away with 700 for privileges. There are a number of other security settings that I will need to look at after the conversion and we have things working.

Posted: Wed Nov 28, 2007 5:42 am

Just keep in mind that when new files are uploaded to Gallery, they will have the default permissions associated with the user's umask so most likely any new ones will be 644. I say this only due to the 700 comment above, unless, of course, Gallery is changing the permissions of their files after uploading... that would be cool. Wink

Posted: Wed Nov 28, 2007 8:39 am

Everything in the Gallery data directory is 777. How it gets that way I have no idea but many of the files are uploaded. No, I spoke too soon. I just checked my test site and it appears the directories are 777 but individual jpg files are 666.

Permissions can be a total nightmare with Gallery M. I actually think PHPsuexec is going to help a lot, long run but I'm anticipating some cut over issues.

Posted: Wed Nov 28, 2007 9:33 am

fkelly wrote:

They heartily endorse PHPsuexec and seem to be saying we could get away with 700 for privileges

Just remember a 700 means that the owner only has r-w-x permissions. No public access at all is allowed.

Posted: Sun Oct 05, 2008 2:13 pm

Well, phpsuexec is a very secure thing, but with the many cases of conversion, I've written a simple command that does what needs to be done with phpsuexec.

Save this to a file in your /usr/bin directory, it doesn't matter what you name it.

Code:




#!/bin/bash








# If the user is root, let's make sure they used the script properly by doing: command user


if [ $USER=='root' ];then


 


   if [ -z $1 ]; then 


      echo "You need to specify a user"


   else


      User=$1


   fi


else


 echo You cannot run this!!!


exit


fi








#Now, let's make sure the user exists, This only works on cpanel servers.





if [ -f /var/cpanel/users/$User ];then





        cd `/scripts/gethomedir $User`/public_html/


        find `pwd` -type d -exec chmod 0755 {} \;


        find `pwd` -type f -exec chmod 0644 {} \;





   if [ -f php.ini ];then


          echo php.ini exists in public_html, will make changes to the php.ini


   else


     


     #grab the system's default php.ini contents and put them in the php.ini of the site. 


     #In Suexec, the php.ini do not append eachother. So the php.ini needs to be complete.


     echo Grabbing the main php.ini and putting it their public_html


     cat `php -i|grep /php.ini|cut -d'>' -f2` > php.ini


 


   fi





#do the .htaccess work





 phpd=`grep php_ .htaccess`





   if [ -n "$phpd" ]; then


    


    replace "$phpd" "#$phpd" -- `/scripts/gethomedir $User`/public_html/.htaccess


     echo SetEnv PHPRC `/scripts/gethomedir $User`/public_html/php.ini >> `/scripts/gethomedir $User`/public_html/.htaccess





     echo Changes to the .htaccess Complete.


     directive=`echo $phpd|sed -e s/'='/' '/g|awk '{print $2}'`


     settings=`echo $phpd|sed -e s/'='/' '/g|awk '{print $3}'`


     replace=`grep "$directive[ ]=" php.ini`


     phpinicond=`replace "$replace" "$directive = $settings" -- \`/scripts/gethomedir $User\`/public_html/php.ini`


     


      if [ -z "$phpinicond" ]; then


       echo Changes were not made to the php.ini, appending with new directives


       echo $directive = $settings >> `/scripts/gethomedir $User`/public_html/php.ini


       fi


      echo Changes to the php.ini, Complete. 


   fi





 #make all files in cgi-bin back to 755


 find `pwd` -type d -name cgi-bin -exec chmod -R 0755 {} \;





 #change ownership to $User:$User


 find `pwd` -exec chown $User:$User {} \; 





#additions under HERE





else


  echo $User does not exist


fi

chmod 0700 /usr/bin/command
To run it, as root: command user

I ussually name it, fixsu , so I'd run it:
fixsu cpuser
Where cpuser is the cpanel username.

This does change the ownership of public_html to user:user and it changes the permissions to 755.

You can add the following to it Under "#additions under HERE":

Code:




chown $User:nobody `/scripts/gethomedir $User`/public_html


chmod 0751 `/scripts/gethomedir $User`/public_html

Really in Suexec, it's not necessary, but some people like to have it. So whatever you like.

I think I might get banned for this, lmao

But it does the conversions from .htaccess to php.ini, and fixes the permissions and ownership. This must be run as root, as there are too many possible exploits for it.

I would not trust this script to be run by the user, AT ALL!!!

Edit: I made a couple of tweaks and such, all for better usage. And fixed a problem with the one bit of code for the setting of the environmental php.ini.

I have been using this code on my own servers since I wrote it and posted it here.