L is for Linux, A is for Apache, and P is for PHP
Before providing instructions for two of the tweaks I made to WordPress 1.2–multiple weblog emulated support and generating static pages–I need to spend some time on the issue of permissions and writing to directories from a PHP application.
Typically, when a web page is accessed from the Internet, it starts a processing thread in the operating system to allow the web server to serve that page. If you have followed this series and bravely embraced SSH, you can log into your site now and take a peek at these processes just by typing the Unix command, ‘ps’ (short for process status). To see processes other than just your own, and to get a nice, full listing of information, use the command options of ‘e’ (for every process), and ‘f’ (for full listing):
$ps -ef
You’ll get a lot of stuff back, but some of what you get back should look similar to the following:
nobody 19905 24708 0 16:58 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 20054 24708 0 16:59 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 20059 24708 0 16:59 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 21016 24708 0 17:00 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 21018 24708 0 17:00 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 21019 24708 0 17:00 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 21022 24708 0 17:00 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 21095 24708 0 17:00 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
These are threads serving web requests. The first column in the output is the ‘owner’ of the process, and as you can see, requests to the Apache web server are owned by ‘nobody’.
When an Apache web server is started, it’s started by the special user known as ‘nobody’. By restricting the environment in which ‘nobody’ operates, only a narrow window of accessibility is allowed into the system, to prevent or at least slow down malicious activity. After all, ‘nobody’ owns any directories, or belongs to any groups–what can it do?
(That’s not to say ‘nobody’ owns all web page accesses. A CGI-based application, such as Movable Type, can operate with expanded permissions in an environment (implemented through the application of a web server add on, such as suexec) that redefines the owner associated with the web request process: instead of the generic ‘nobody’, the page runs within a process controlled by the actual owner of the web site. This means that when you access a page from within these cgi-bin directories, they operate with all the permissions of the owner of the subdirectory.)
Though that nobody owns most of the web requests on your system, but since you’re not a system admin or webmaster, what does this mean to you? A great deal, as a matter of fact, if you’re using applications built on PHP. Any action within PHP that results in output to a directory requires setting permissions on the directory to allow that nefarious user, ‘nobody’, write access. Since ‘nobody’ is really anybody that means setting a directory to wide open write access.
If the PHP application allows file uploads into this directory, the file name can be manipulated in such a way that it exposes files that normally shouldn’t be read–such as the /etc/password file containing user/passwords for the server. In addition, other combinations of file names and actions can result in directories being deleted, or sensitive material being placed in system that when accessed via web server can result in odd behavior. At best.
Having a directory open to global write access is a system vulnerability. However, before you run to your server to wipe your PHP weblogging software from it, take a deep breath, relax, and access your administrative pages for your software. The first thing you should hit is a login page to provide a username and password.
PHP applications that have some form of file upload almost always have some form of password protection to keep that infamous ‘nobody’ from accessing the page, and hence uploading the ‘bad stuff’. Though the server sees the access as ‘nobody’, the application ensures that the access is from ’somebody’.
Of course, this isn’t a totally reliable solution–someone could also run a sniffer on the network, grab your password if you don’t access your weblog tools using SSL security, https, and then log into your system and do havoc. But then, they can do this with those cgi-bin applications I mentioned earlier, too.
(There is a version of suexec being circulated about for PHP called phpsuexec. However, with the limitations associated with it, including running PHP as a CGI application, I can’t see its use spreading very quickly. )
The short end to this long story is that write access and file and directory permissions are always an issue when working with PHP applications. However, by restricting global write access to as few a directories as possible, wrapping authorization about the software that does the writing, and then ensuring that good user permissions are maintained by the system administrator for our computers, unless we get specifically targetted by some of the more clever of the bad guys, we should be safe. And let’s face it: nothing keeps out the really clever bad guys, regardless of what we do, other than unplugging the machine from the Net.
However, having to enable global write access for directories where uploads or changes are going to land also means there’s some extra work for you when installing the software. PHP-based weblogging software such as WordPress almost always require that at least one directory is set to global write (usually detailed in the installation instructions). Not a problem you think, but when you create the directories, they’re initially created without global write permission. Unfortunately, since you’re in a fever of anticipation about getting the software up and running, you tend to forget to change the permissions and get an error such as this:
Sorry, I can’t write to the directory. You’ll have to either change the permissions on your WordPress directory or create your wp-config.php manually
More likely, you’ll get a less friendly message, such as the following:
Warning: fopen(../wp-config.php): failed to open stream: Permission denied in /home/…/wordpress2/wp-admin/install-config.php on line 122
If you’ve installed PHP applications before, you know what’s wrong; but if you haven’t it may take some help from support folk to figure out what’s going on. Well, until now – now you know why you’re getting those errors.
Are you curious as to why the global write isn’t set when you first create the directory? Of course you are. It’s kind of like the seventh Harry Potter book of Unix knowledge.
When creating a directory for the first time, there’s a basic set of permissions given it by default that have been predefined for our user accounts by our system administrators. This is called the umask or user mask, named that way because setting permissions can be seen as a masking operation.
Just think of file and directory permissions as a filter with three holes: small, medium, and large. If you throw a bunch of rocks into it and all the holes are open, all the rocks will fall through. However, if you cover the large and medium holes using masking tape, then the only rocks falling through are the small ones.
Masking tape. Masking. Mask. User mask. Umask. And here you thought that Unix terms were bizarre.
Anyway, no system administrator worth her salt would ever define a umask that automatically sets directories to write enabled: not unless it’s her last day of work and she’s just won the lottery. And she’s a malicious bitch to boot.
No, you, as just any old user on the system, will have to change the global write permissions using the chmod command, and has luck would have it, I’ve already written how to use this command.
(Or you can have your FTP program change the permissions for you if you’re bypassing the hacker track on this series. )
Just remember to keep those file write errors in mind as you read the next few LAMP essays – not that there’s any doubt you’ll forget this essential element after this essay. Why, I bet you never forget write permissions on a directory ever again.