Getting File Permissions Right In WordPress

I don’t think too many people, who can boast at least an ounce of credibility, would disagree with me when I say WordPress is becoming the killer app. At least as far as blogging platforms are concerned, anyhow. Mix this with the fact that the projects and work I am tasked to daily are becoming exponentially more complicated, interesting and downright fun, I’ve decided to dive in to what I’ve previously considered as a somewhat egotistical world of blogging.

But where I have previously sheiked “Ooh, web log!” in a sarcastic high-pitched voice, I shall now subdue and admit defeat, letting my hypocrite little fingers do the talking.

If nothing else, I will treat this blog as a diary, or armoury, of things I want to remember or share about the things I find interesting. I firmly believe there has to be at least a handful of people in the world that will find my writings interesting, if no more than for scientific or sociology reasons. Alas, as long as it gives me a place to document what I enjoy, it shall serve some purpose.

I better get to the point. Yes, WordPress is pretty amazing; it’s pretty, usable and powerful all at the same time. It does exactly what it says on the tin, but very, very well. The installation process lasts just minutes until you’re all ready to go. Well, almost. If you want to upload images to place in your posts, or automatically change your permalinks settings without getting your hands dirty, then you will have probably met a few file permission problems.

These problems seem to crop up a lot for those people who run WordPress on a VPS, possibly using web server management software like Plesk. The problems arise when all your web pages and documents are owned by your personal user account, but Apache, our old faithful friend, runs as a different user.

As we all know, a file has set permissions for its owner, the group it belongs to, and for everyone else. These permissions are read, write and execute. By default a files permissions are set to 644 (read/write for the owner, read for group and read for everyone else). This means that whenever Apache wants to write something, as it does when you upload media, or try make changes to you .htaccess file, it will not have write permission as it doesn’t own the file, nor is it in the same group.

In the past I tackled this problem in a number of different ways. The first way, which anyone with a hint of care for their security would grimace at, would be to set permissions on those files that need writing to to 777 (read, write and execute access for everyone!). This is bad.

As I started taking a little more care I thought it would be better to keep the permissions nice and tight, while still allowing the write access for Apache. I ran the chown command (change ownership) to set the files to be owned by the user that Apache was running under. For instance, Apache usually runs under a user like apache, www-data or nobody. Chowning the files in the web root to that user would give Apache the access it so craved, and all was hunky-dorey.

I can’t help but look at the above technique and grimace a little too, though. What happens if you happened to want to edit a file on the fly in Vim? Maybe you need to FTP some files in to a specific folder on the server? Your normal user account would have lost write access in many places — the amount of chowning and chmodding you would have to do on a regular basis can start to get a little bit unbearable.

Surely then there is a better option? Well, yes. But there are a couple of things you need to bear in mind or you may start going round in circles feeling like you’ve achieved nothing.

The third and final method (for me, at least) is to find out what group your user account is (on Plesk this is probably psacln) and add your Apache user to that group too. For instance, if I was running Apache under the user www-data, and my user account was leonard with a default group of psacln, I would run the command:

$ usermod -a -G psacln www-data

Now it should be obvious that if we allow write access to the file’s group, Apache (running as www-data) should be able to write to it. The simplest way to do this is to run the command:

$ chmod g+w .htaccess

Here, you would replace .htaccess with whatever file (or folder) you want to change permissions on. Of course, you can use the recursive -R flag if you want to apply the permissions on the folder and all the files and folders beneath it (such as wp-content/uploads).

Note: I have seen varying results from the above changes on different operating systems. You may find that you need to restart Apache for the changes to work. This would be something like:

/etc/init.d/httpd restart

…depending on what version of Linux you’re using. Consult your OS documentation! If it still doesn’t work, continue on.

It all seems a little bit easy, doesn’t it? Well it kind of is really. But as I said there may be one or two caveats that catch you out. If this still doesn’t work for you (and especially if you are using Plesk) then it is likely PHP safe mode is turned on.

PHP Safe mode (set in the Web Setup of a domain in the Plesk control panel), where you enable PHP, Python, CGI, etc, is on by default, and can act rather strangely if you don’t know what to expect. When safe mode is on, PHP will only let you write to a file if you own it. Yes, even if you are in the same group, and have group write permissions set correctly. What’s more, when you create folders inside other folders, they will automatically inherit the permissions of the domain user account, not the user Apache is running under.

Now it’s likely there are things you would probably want to consider when turning PHP safe mode off, especially in a shared environment, but for me it was just an inconvenience that I wanted to go away. So it did. Now, I own all my files and let Apache write to a specific one or two. Problem solved.

Oh, and don’t forget… running commands like chmod and chown will require superuser access. On some systems you can get away with running sudo su - or just su -, but you must be in the sudoers file. If this is not the case, you will have been given a root password, which you can log in to to run these commands.

Again, this all seems so trivial and downright simple. But coming from past experience, when you are still learning your way around the Linux operating system, permissions can be a little daunting to say the least. There are thousands of repeated posts on forums and blogs across the web asking the same questions. Hopefully you (and I) will never have to worry about these problems again.

With that said, welcome to my blog!