Newbiesite Blog Newbiesite Blog

December 12, 2009

Fine tuning of apache with suPHP

Filed under: Web Hosting — Newbiesite Admin @ 4:03 am

Author : Ethan

The earlier version was PHPsuExec but that is quickly being replaced by suPHP and the two do basically the same thing. suPHP provides an additional layer of protection on servers.

On most Apache servers, PHP runs as an Apache module. This is the default method of installation. Many hosts have this setup because it is default and potentially they do not realize that it is also possible to configure PHP as a CGI. Running PHP as a CGI can be more secure whilst also avoiding file and directory ownership issues.

Like Apache’s own suexec, suphp is a solution that allows PHP to run as the user and group that owns any particular website on a shared hosting server.

Working of suPHP

suphp consists of two components:

a) mod_suphp, an Apache module that replaces mod_php

b) suphp, a setuid binary that replaces Apache’s suexec

suphp is compiled and installed in the same way as any other Apache module. suPHP provides the facility to have all scripts running the relevant user account instead of the user ‘nobody’ which is the user that apache/php would run under on a server that is not running suPHP. This feature allows us to more easily track and isolate any potential security breaches that come in via malicious or runaway script usage very quickly, avoiding unwanted or un-authorized scripts from running for a lengthy period of time.

suPHP also does away with the requirement of using 777 permissions on directories/files that need write permission. In fact if a directory and/or file has the permission set to (CHMOD) 777 and it is access via a browser, then an internal server error 500 will be generated. The highest level of permissions that a user can use on a suPHP enabled server is 755. This permission setting is sufficient enough for any directories/files that needs to be written to.

Advantage of Using suPHP

The benefit of using suPHP besides better security, is that it will make any PHP applications (most often CMS systems) such as Mambo more user friendly. Case in point: If you upload/install anything via Mambo such as a template on a non-suphp server, then those template files will be owned by ‘nobody’ and you will not be able to edit them manually or even delete them from your account. This ownership issue is done away with suPHP. On a suPHP enabled server, those same template files will be owned by the account username and the account holder will be able to manipulate those files as he sees fit. No longer do you need to use (chmod) the dangerous file permission of 666 or the folder permission of 777 to make things writable.

The correct permissions should be:

Writable Folders: 755

Writable Files: 644

Files that need to be un-writable: 444

Common issues after switching to suPHP

Under the old Apache Module mode it was possible to manipulate the PHP settings from within a “.htaccess” file placed in the script’s top-level directory, this was also recursively applied to all other directories below it. Now, when PHP is running as a CGI and suPHP protected, manipulating the PHP settings is still possible however you can no longer make use of a “.htaccess” file. Using .htaccess with the required PHP prefix of “php_value” will cause a “500 internal server error” when attempting to access the scripts. This is due to php no longer running as an Apache module, thus Apache is unable to handle those directives any longer. All php values should be removed from your .htaccess files to avoid the 500 internal server error. Instead, create “Local php.ini” file to manipulate the desired php settings. The php.ini file is a configuration file that the server looks at to see what PHP options have been made available to the server or what their setting are, if different from the server’s default php.ini.


Php script doesn’t work or have an error message.

  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,

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

  1. Check for .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.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment

You must be logged in to post a comment.

Powered by WordPress