phpsuexec

phpsuexec allows a hosting company to detatch php from the Apache server (usually php is installed as an Apache "module") and run it like a regular cgi inside the user's own account. This has many advantages for the host, chiefly, that they can track which user is eating up all the resources. It also has many advantages for the webmaster, too.

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 you 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.

Or simply When PHP runs as an Apache Module it executes as the user/group of the webserver which is usually "nobody" or "apache". php suEXEC changes this so scripts are run as a CGI.This means scripts are executed as the user that created them. If user "snow" uploaded a PHP script, you would see it was "snow" running the script when looking at the running processes on your server. It also provides an additional layer of security where script permissions can't be set to 777 (read/write/execute at user/group/world level).
Firstly, of course, nothing works. Your pages will likely not load, and you will probably be greeted with a nice 500 error page instead of your beloved website. If you are still reading this, I'll assume phpsuexec is something that interests you, so here's what you need to know..

File permissions. php scripts can no longer have their persmissions set to 777, or live in folders with those permissions, either. Folders should be set to 755, and php scripts to 644. If some script you downloaded says it needs to be set to 777 (world-writable), ignore it, and set it to 644. Your scripts are no longer run as user "nobody", but as YOU, so as long as the owner (you) can write to the file (the first 6) then all is well. Same story for log files, comment files, etc. Where they used to need to be 777, now they don't. 644 is just fine, even 600 if they are private things.

If you have shell access to your site, you can fix the whole lot in one go, like this..

for i in $( find . -name "*.php" ); do chmod 644 $i; done  for i in $( find . -type d ); do chmod 755 $i; done

and that's all your file and folder permissions fixed. But you still get 500 errors,

 

php directives. Becasue php has been disconnected from Apache, those php directives inside your .htaccess files are now completely meaningless to Apache. Hence the error. You need to remove all those php directives from your .htaccess files. Again, this is easy to do in one fell swoop..

for i in $( find . -name ".htaccess" ); do mv $i $i.old; sed 's/php_value/#php_value/g' $i.old > $i;rm -f $i.old; done
(all commmands are entered on a single line, even if it may appear split into two in your web browser) Now all php directives will be commented out in every .htaccess file, and you can at least see your page. (if you have "php_flag" directives, use a similar command for those, too). Still not working?

AddType directives. If you parse non *.php files as php, for instance generated CSS (like corz.org) then statements like this.. 
AddType application/x-httpd-php .css .style
will now fail dramatically. The solution is simple, use SetHandler instead, like this.. 
# for suexec..  <FilesMatch ".(css|style)$">    SetHandler application/x-httpd-php  </FilesMatch>

And now all *.css and *.style files covered by that particular .htaccess will be parsed by the php machine. Excellent!

Options -ExecCGI will also prevent your php script from running, of course. While we're at it, here's some other stuff you need to know..

What is phpsuexec and why should I use it??

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 you 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 you 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.

What is the downside to using phpsuexec?

Performance: Since php is running via a CGI interpreter which is going to add an overhead to your CPU
PHP Scripts: Some scripts do not like the phpsuexec CGI environment as it changes certain PHP internal system variables causing them to fail.
.htaccess: Manipulating php settings is not possible (use a local php.ini instead)
Security: Files / Directory permissions given a world read+write+execute 777 will not work, instead these files will need to be changed to 755
PHP Accelerator: Zend does still function however other popular Accelerators such as eAccelerator do not.
urls: Variables in URL not encoded as regular variables that is variables inside the URL path, not expressed like view.php?=view will not work.

What is the upside to using phpsuexec?

Security: it is far more secure without global world write permissions.
File Ownership: Files are owned by the user/usergroup rather than nobody/nobody

How do I enable it?

You will need to recompile Apache with PHPsuexec enabled.

The following steps will help you in this.

 

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

 

for i in $( find /home/*/public_html/ -name "*.php" ); do chmod 644 $i; done

for i in $( find /home/*/public_html/ -type d ); do chmod 755 $i; done

 

for i in $( find /home/*/public_html -name ".htaccess" ); do mv $i $i.old;
sed 's/php_value/#php_value/g' $i.old > $i.old1; sed 's/AddType/#AddType/g'
$i.old1 > $i; rm -f $i.old1; done

 

cut -f2 -d ':' /etc/trueuserdomains > /root/list

 

check root/list

/root/list

 

for i in `cat /root/list`; do chown -R $i.$i /home/$i/public_html/* ; done

 

 

easyapache

 

http://forums.cpanel.net/showthread.php?t=53623&amp;highlight=error%3A+file+has+no+execute+permission (edit apache conf)

 


The downside however is that there can sometimes be issues with any .htaccess directives you have, specifically in regards to PHP directives. You may have to remove PHP directives from .htaccess and move them into a php.ini file inside of your site's document root. In addition, there could be some performance loss (also known as seeing a higher server load) as a result of all php scripts being ran as a seperate CGI instead of as part of the Apache module.

 

 

for i in $( find /home/*/public_html -name ".htaccess" ); do grep php_value $i > php.ini.1; sed 's/#php_value\ //g' php.ini.1 > `echo $i | sed
's/\.htaccess/php.ini/g'`; done

OR

 

for i in $( find /home/*/public_html -name ".htaccess" ); do grep php_value $i > php.ini.1; sed 's/#php_value\ //g' php.ini.1| sed 's/\ /\ =\ /g' > `echo $i | sed 's/\.htaccess/php.ini/g'`; done

 

for i in $( find /home/*/public_html -name "php.ini" ); do sed 's/\t/\ =\ /g' $i > php.ini.1; cat php.ini.1 > $i; done

 

http://corz.org/devblog/2006-Q1

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$