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.
Every 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.
While 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 modx-2.0.0-beta-5.zip.
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.
My 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
Long-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.
Related 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 'eaccelerator.so' 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.
