Category Archives: SuExec

suPHP and “Server Error”

At Hosting Marketers all our servers run on suPHP, this means that folders must be 755 and files 644 or even less, this blog post will explain why.

Hosting Marketers does not allow 777 on files which process server-side (i.e. PHP). However, many scripts require you to change your files to 777.

I can tell you that 755 will work in lieu of 777. You will not need to use 777 on PHP files or folders.

The concern is giving writable permissions to Group and World. This allows hackers from the world wide web to edit your files. Thus, the last two digits of file permissions should never be 2, 3, 6, or 7.

The problem is when you install a PHP script, the script needs permission to edit files. Traditionally, PHP is treated as ‘nobody’ on the server. Therefore, PHP is treated the same an any unknown visitor and must obey the permissions granted to World.

The solution to this conflict is to treat PHP as the Owner. Hosting Marketers has done so by implementing a special PHP security environment known as suPHP (or phpSuExec).

With suPHP, all PHP scripts are allowed the same permissions as the Owner, and outside visitors are still restricted by the World permissions. Therefore, 755 is the perfect number; it allows all actions for PHP and only reading/viewing for potential hackers.


If a server requires 777 permissions on folder in order for PHP to write to that folder, then your server is only as secure as the least secure account on that server.

If a server requires only 755 permissions for PHP uploads (i.e. with suPHP) then each account is on their own.

A couple of examples might illustrate this better.

Say a server has two accounts on it and that server is running PHP through Apache (i.e. no suPHP, 777 directories are required for PHP uploads). The two accounts are and is running a Gallery script, that requires the upload directory to have world-write enabled, permissions 777, but the owner of always keeps their Gallery script up-to-date and practices the best security policies. on the other hand, they don’t care about security. They are running an old WordPress install, and old Joomla script, and perhaps some other scripts that they never used and never updated or removed.

When gets hacked into because of the outdated scripts, those hackers may be able to place a PHP shell script onto the account, and they would then have access to write files into’s upload directory, the directory on that has 777 permissions.

This doesn’t seem quite fair, because was keeping their scripts up-to-date, yet their account was also being used in the exploit.

Now consider this same scenario where and are on a server running suPHP. still has the Gallery script, but because suPHP is in use, the upload directory for the Gallery script can survive with permissions of 755.

Now when gets hacked because of their old and outdated scripts, that hacker cannot upload anything onto the account because does not have any open directories. The hacker can go wild on the account, upload and delete anything they want. But the blame always goes back to the owner of, why wasn’t that person keeping their scripts up-to-date?

This is why, Hosting Marketers, on its servers always uses suPH!

Now an extra word of advice with suPHP. In the above example, I would recommend that keep their Gallery scripts config file set with a permissions setting of 600 or even 400. The reason being, if the config file (the file that contains that Gallery’s database login credentials) is using the default permission setting of 644, then the hacker from would still be able to read the config file (they would be able to READ any files that are set to 644 or above, just not write to them). This is why you should always create a MySQL username and password for accessing your MySQL databases, and NEVER use your main account username and password in your script’s configuration files for accessing MySQL databases. If you do use your main account username and password in the config file, and the config file has a permission setting of 644, then hackers from would still be able to read the config file, get your login information, and then FTP into your account.

register_globals on servers with SuExec

First of all allowing register_globals on, on a server is real stupid, it is a security risk that no hosting company should accept, but sometimes for old scripts it is necessary to have it on, in this case should be enabled on the customer account on the .htaccess file or if the server is running with SuExec support then on the php.ini file.

Usually entering the line:


to the php.ini on the public_html should work, but on some servers we have noticed that this is not working. Unfortunately we do not know the exact reason for this issue, but we have another method to enable this.

First create a file called php5.cgi with 755 permissions and add the following in it.

exec /usr/local/cpanel/cgi-sys/php5 -c /home/account-username/public_html/php.ini

(change the user names, and copy the php.ini file in to the public_html)
Then add the following lines in the .htaccess file.

Options All -Indexes
AddHandler application/x-httpd-php5 .php
Action application/x-httpd-php5 /php5.cgi