Monday, November 23, 2009

What is suPHP or PHPsuExec?

SkyHi @ Monday, November 23, 2009
Yes, this is covering technical (geeky) aspects but I am trying to put in layman’s terms.

I wrote a post talking about having suPHP on the server was actually a benefit for people using WordPress 2.7. In response to that post I was asked, “What is suPHP?” I will attempt to answer that here but I will have to put out some background first.

suPHP is a program that controls who can access certain files. The earlier version was PHPsuExec but that is quickly being replaced by suPHP and the two do basically the same thing.

Now to explain about permissions I am going to have to start at the very beginning.

It starts with scripts, scripts are programs that run on your server that give your website or blog the ability to process information that can be stored or displayed when requested. WordPress blogging software is a script.

All script files need to be authorized to run on the server and this is done by setting permissions (CHMOD). There are three categories that permissions can be set for and three types of permissions.

The categories are:

User – this is the site or file owner.

Group – this is for select members that have access to certain areas of your server or script.

Other – covers anyone that isn’t the user or the group.


Read - allows the file to be read

Write – allow the file to be modified

Execute - allows the file to be run on the server.

The permission are usually described with either letters or numeric values

1 or x = execute
2 or w = write
4 or r = read

Most commonly you will see instructions telling you to set the permissions (CHMOD) to a file to a number like 755. The numbers come from a sum of the permissions granted. In this case it would be:

User = 7 – this is 1 for execute, 2 for write and 4 = 7
Group = 5 – this is 1 for execute, 4 for read = 5
Other = 5 – this is 1 for execute, 4 for read = 5

This permission would let anyone that comes to your site read the file and execute it but they couldn’t change it only you (the server) can change the file.
PHP scripts usually run with the user as “Nobody”. This means that the control of the file or directory is directly related to the permissions set for the file.

Since “Nobody” is not the User or a Group member that means it is Other and for the script to run properly you might have to set the permissions to a file or a directory to allow all these categories to use the file. This would be a read, write and execute for all categories (777)

The problem with this is that you are letting people from off your server execute files. This opens up the possibility of adding code to a URL and giving them access to your entire site depending on the file they can get into and how it is coded.

This is a big, make that BIG, security risk and should be avoided.

Now enter suPHP or PHPsuExec, both of these will stop PHP from running as “Nobody” and make it so the files can only be written by the User.

This is one layer in defense against hackers but it does affect the way that you have to set your permissions on your site.

If your server is running suPHP or PHPsuExec and you are told to give a folder or directory the permission of 777 and you do so, when you try to run the program you will probably get an error, usually a 500 Internal Server error.

How do you know if your server is running suPHP or PHPsuExec?

Basically, if you set your permissions on a folder to 777 and you get the 500 Internal Sever error your server might be running suPHP or PHPsuExec, but it could be another error with the script. Your best bet is to ask your hosting service if you are. I know HostGator and Niche Simple (two of the hosting companies I use for blogs) use it and more and more hosting services are starting to use it.

The key thing to remember is that if you are installing a script and you have suPHP or PHPsuExec running on the server and you are told to set permissions (CHMOD) to certain files and folders and you do this and the script doesn’t work, change all your folder/directory permissions to 755 and all your file permissions to 644 and try again this usually fixes the problem.


suPHP vs Running PHP as an Apache User (using mod_php)

I had problems installing MODx Revolution (« a cool, new PHP-based Content Management System). I tracked the source of these problems to 'permission' settings applied to certain files & folders within the /modx installation directory.

suPHPEvery file and folder on a Linux server has an assigned permission setting. These settings control WHO can do WHAT (.. to/with a particular file or folder). The 'WHAT' aspect addressees the authorization to:

  • read (4)
  • write (2)
  • execute (1)

.. or some combination thereof. For example » 6=4+2 = read + white, while 5=4+1 = read + execute, and 4 = read-only. The 'WHO' part is divided into the following categories:

  • OWNER .. of the file/directory (me) Represented by the number listed FIRST.
  • GROUP-member .. assigned permission to access the file/directory (set by me)
  • THE WORLD (.. represented by number listed LAST)

The most-permissive of these settings is » 777 (4+2+1) which lets any-BODY do any-THING (.. known as 'world-writable'). In other words, it would let anybody (including a hacker) » read, write & execute my file(s). This is why most admins cringe at the idea of setting a permission to 777.

The first 7 is cool, cuz that lets ME (the file's 'owner') do whatever I want. The second 7 is also cool, cuz it lets the members of a GROUP (that I select) do certain things (such as read, write & execute files). It's that last 7 where the trouble lies. It lets anybody else do whatever they like. Not good for security.

MODx 2.0 RevolutionWhile installing MODx, I discovered (thru trial-n-tribulation) that I needed to set certain directories (deemed 'writable') to 777 .. in order for the program to install. And I wasn't the only one experiencing this problem.

For me, sadly, this was a deal-breaker. I was excited about the new MODx Revolution (currently at beta5). It has some really cool features. But I was unwilling to operate with any files or folders set (permanently) to 777.

Before abandoning my quest however, (to explore MODx Revolution), I decided to see if I could find a solution.

While searching, I noticed some files & folders within the /modx directory that had an 'owner' listed as » 'nobody' .. something I'd never seen before. [ The 'owner' of all other files on my server is normally listed as 'rad.' ]

This mysterious Mr. 'nobody' (I learned) is the default Apache user. (Tho I hear it can sometimes be listed as 'apache'.)

In a practical sense, when your system is configured to run PHP as an Apache user (which is common .. also called the 'web server user') .. any files or folders CREATED by the PHP program/script will be assigned an owner of 'nobody'.

••• today's entry continues here below •••

Most of the files and folders contained in the MODx program have an assigned owner of 'rad,' which is normal. These normal permissions get assigned when I explode the MODx archive (*.zip) on my server (« physically located in Chicago) .. via the Linux shell command » unzip -a

But when I actually launch the MODx installation script (located in the /setup directory), it creates a handful of OTHER files & folders .. all of which are assigned an owner listed as » 'nobody'. This is where the problem stems from .. when the installation script is run.

The guys at MODx forums said I shouldn't have to run anything as 777. They said 775 should suffice (when running PHP as an Apache user like I was). But 775 wouldn't work for me. I've never had to run 775 before .. for anything. Usually, I run directories at 755, which grants no one the permission to WRITE except me (the owner).

UPDATE - I misunderstood. They said 775 would be fine LONG AS I chgrp'ed the directories that need to be writable (.. giving user Mr. 'nobody' group access to those directories). Yeah, that would work. But without group 'nobody' receiving group access, MODx needs 777 to install.

The Tech Sppt guys at my web host however, advised AGAINST changing ownership, claiming that woulf interfere with cPanel's ability to back-up my files.

Side-note » the term 'DSO' (Dynamically Shared Object) is associated with running PHP as an Apache user. DSO is a PHP handler that allows Apache to interface with PHP. Apache and PHP have close integration and work well together. The term mod_php is synonymous with DSO, and you'll hear both used interchangeably. cPanel uses the term DSO, so this is the term most used by web hosting providers that use cPanel.

Running PHP as an Apache user (like anything) comes with both pro's and con's. It has the advantage that it's GOOD for performance, allowing you to cache files. But it's BAD for security, requiring looser permission settings. Moreover, any hacker worth his salt (scripts) knows that 'nobody' is the default Apache user.

suPHPMy research eventually took me to a program called » suPHP. (I believe the 'su' stands for Super User, but not sure.) Here's what suPHP says about itself on its homepage:

suPHP is a tool for executing PHP scripts with the permissions of their OWNERS. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the user id of the process executing the PHP interpreter.

The biggest advantage of suPHP is improved security (over mod_php). This page says, PHP is the #1 method hackers gain access to customer accounts.

I like that it also makes PHP-based programs (such as CMS's like MODx) more user-friendly. suPHP also makes it easy to determine what user/site on a server is causing a high CPU load with PHP, whereas with DSO it takes longer to inspect. The downside is a performance hit (.. which I can live with).

The performance hit you take with suPHP ranges anywhere for 30% to 30-X, depending on which source you consult. In other words, it's significant. 30% isn't bad, but 30-fold (3,000%) is huge. It all depends how much traffic your site sees, and how many web pages you're serving.

suPHP is enabled thusly (after which you would restart Apache, which should take 15-30 secs):

  • Via WHM » Main » Service Configuration » PHP Configuration Editor .. or
  • Via SSH » /usr/local/cpanel/bin/rebuild_phpconf 5 cgi suphp

MODx 2.o RevolutionLong-story short » soon as I enabled suPHP, all my problems magically disappeared. MODx Revolution installed flawlessly. No longer did I see an owner named 'nobody'. All folders worked geat with/at permission » 755. Most files got » 644 & 640. Beautiful.

Afterward, I played around with permission settings, and it surprised me to discover that setting folders to LESS restrictive permissions (such as 775) generated errors. Seems suPHP does not like the less-restrictive permissions. I'm not sure why that might be. UPDATE - this may be a security feature of suPHP.

The terminology can get confusing (with handlers, users & owners) but my conclusion is that » suPHP is definitely the way to go. It greatly simplifies running PHP-based scripts, such as those within Content Management Systems like MODx.

Most importantly, it provides improved security .. by allowing you to streamline permissions. If suPHP does cause excessive server-usage issues, I would argue it's time to upgrade to a more-powerful server .. or try something like LiteSpeed.

suPHPRelated Notes Collected Along the Way

Don't confuse suPHP & PHPsuExec with suExec, which is used for running CGI scripts (not PHP). PHPsuExec & suPHP are similar, with suPHP being a newer/better version of PHPsuExec.

When using suPHP, the only time you might need to add a line in the .htaccess file (such as » suPHP_ConfigPath /home/user/public_html/modx_directory ) to specify the location of the php.ini file is when declaring explicitly which php.ini file to use. This should not be necessary when using a global php.ini file. [ I did not require this addition to .htaccess. ]

Also, if you do this, don't use cPanel. Rather use the EZ php Config wizard to handle your settings. Doing this in cPanel will generate a 500 server error because PHP directives are not allowed in cPanel .htaccess files.

After switching over to suPHP, permissions within the /public_html directory should be set to no higher than 755 for folders and no higher than 644 for files.

After switching to suPHP, eAccelerator will not run, regardless if it set in the php.ini file. Best to formally disable eAccelerator (via SSH) by placing a ';' (semi-colon) in front of the eaccelerator settings in the '/usr/lib/php.ini' file.

If you were to switch back to using PHP DSO (mod_php), you would want to re-add the '' extension within the WHM's php.ini section and ensure that the /tmp/eaccelerator file is writable for caching to take affect. You will also need to change the following line within your php.ini file:

eaccelerator.enable = "1"

suPHP will not work with any opcode caching software such as eAccelerator or APC.

Along these lines of running PHP with better security and performance, there are new, high performance web servers, such as LiteSpeed (based in New Jersey) .. to replace Apache. Notice the top-right corner, where it says » LiteSpeed is better than mod_php + phpsuexec. (More » here.) My tech support guys at WiredTree say it's very easy/simple to replace Apache with LiteSpeed.

FastCGI is another term (technology) you hear tossed around in these circles. But these new hi-perf servers & FastCGI are topics for another day.

Before closing, I'd like to clarify .. that when we run PHP using mod_php, we are running PHP as part of Apache, as an Apache module. This has certain advatages & disadvantages, as we already mentioned. Good for performance, but not-so-good for security.

When we run PHP using suPHP, we are NOT running PHP as part of Apache. Rather we are running PHP outside of Apache, and thus this method requires an external CGI version of the PHP interpreter.

For more along these lines, here's a Google search preconfigured for the query » suphp vs dso. Here's another preconfigured for » suphp vs mod_php. Here's one preconfigured for » suphp vs fastcgi.