WordPress, DSO and Permissions

I run my server with PHP DSO. 1 It lets me run APC, and I’ve always liked it. It does have some weird problems, mind you, like a tendency to upload files as nobody:nobody, and more importantly it means that you have to set your wp-content/uploads folder permissions to 777. Thankfully there’s a fix!

If you’re not good with command line, scared by shell, and terrified of chmod, you’ll need to find your friendly neighborhood sysadmin to help you out. It’s okay to not feel up to doing this, and it should go without saying that you should make a backup first!

To step back, someone’s going to ask “Why is 777 bad?” Unix permissions are complicated. Every file in UNIX has an owner user and an owner group, and most of the time they’re the same. Mine are ipstenu:ipstenu (which means owner ipstenu, group ipstenu). Now another account on this server, conrel, has conrel:conrel. The groups ipstenu and conrel are both in the same webmaster group, which gives them special permissions. It’s confusing to a lot of people that most webhosts use the same name for the user and the group, but it’s just what we do.

Now for every file, there are three types of ‘ownership’:

  1. User ownership – i.e. the user ipstenu
  2. Group ownership – i.e. the group ipstenu
  3. No ownership – i.e. you who are reading my site

There are also three types of permission levels”

  • read (r)
  • modify/edit/write (w)
  • execute/run (x)

This all works out so when you go in via unix shell and look at your files you see soemthing like this:

-rw-r--r-- 1 ipstenu ipstenu 203789 Oct 5 19:30 stevejobs.png

This means the owner (ipstenu) has rw permissions (which are read-write). The group (ipstenu) has r (read-only), and the world (i.e. everyone else) also has r (read-only). This is an image, no one needs to execute it (which would be an x). 2 These rwx letters correspond to numbers. r = 4, w = 2 and x = 1. So when you see ‘rwx’ that equals 7. 3

So why is 777 dangerous? 777 means ‘everyone has full access to this file.’ Yeah, that sounds dangerous! I don’t want that! The only person who should have full access is you! But DSO doesn’t like to upload files without 777 permissions. In part, this is WordPress’s fault, but really it’s an unholy combination of things. Alex King explains why it happens, and as of WordPress 2.8, you can fix this yourself.

Just override the default file permissions. It’s genius! I tossed this into my wp-config.php file and I was good to go!

define('FS_CHMOD_DIR', (0755 & ~ umask()));
define('FS_CHMOD_FILE', (0644 & ~ umask()));

No, the 0 in front is not a typo. 0755 is an octal value. Octal values must be prefixed with a 0 and are not delineated with single quotes (‘). It’s just how it works.

There is a catch, though. My uploads folder had been set to 777, which meant /wp-content/uploads/2011/10 (this month’s folder) was also 777, which totally invalidated my test. That’s easy enough to go back and fix permissions on your folders. I did it this way because I have some caching plugins that I do not want to screw around with:

find /home/foobar/public_html/wp-content/uploads -type d -perm 777 -print -exec chmod 755 {} \;

find /home/foobar/public_html/wp-content/themes -type d -perm 777 -print -exec chmod 755 {} \;

find /home/foobar/public_html/wp-content/plugins -type d -perm 777 -print -exec chmod 755 {} \;

That code says “Find all folders (-type d) and if they have permissions of 777, change them to 755.” There are more variations on that. 4 If you want to change files, it’s -type f and you’d want something like this:

find /home/foobar/public_html/wp-content/uploads -type f -perm 777 -print -exec chmod 644 {} \;

That will turn all your images back into permissions 644, presuming they were 777 to begin with. Mine were 755.

Permissions GrantedThe last step I had was chowning the folder for uploads and 2011 to nobody:nobody. That was so on month end, I would be able to create folders (like uploads/2011/11 today) without any issues. The other folders, as they already existed, didn’t need the permissions changed. Honestly, I’m not sure if I needed to set the uploads folder to that. I didn’t set blogs.dir for my MultiSite install, and just did the files folder within, since it had created other folders correctly. It’s a hassle, unraveling years of ‘Did it wrong!’ and when you add in that we’re using different tool sets to upload files versus upgrade and all that … well. It works now.

I also kept the upgrade folder with permissions 777, since that just did not want to work any other way. It flat out refused to upgrade any plugins. I’ve yet to try upgrading WordPress itself with this setup, but I suppose I’ll find out soon.

And that’s it! It’s not 100% painless, and it’s much easier if you start out ‘doin’ it right’, but even after you’ve been doing it wrong for over 5 years, you can fix it.

Notes:

  1. For the differences between DSO and SuPHP, read DSO (mod_php) vs. CGI vs. suPHP vs. FastCGI
  2. The “1″ before ipstenu is for the number of files. “203789″ is the size of the file. “Oct 5 19:30″ is the day/time I uploaded the file, and “stevejobs.png” is the name of the file.
  3. There are also options o (other), u (user), g (group) and a (all)… and s … but I’ll spare you that right now. Suffice to say, you can use what you’re comfortable with. I use the numbers most of the time.
  4. I got the code from NixCraft – Linux / UNIX: Change File Permissions Recursively ( conditional )
StudioPress Theme of the Month

Comments

  1. Instead of using DSO (mod_php), why not go with a FastCGI configuration instead? This takes a bit more memory, but is hella fast by comparison. Actually, on DreamHost, I switched to nginx+fastcgi and it’s running nice and smooth (except for the occasional 502 error, which I worked around).

    • APC mostly. Also FastCGI just does not like some of the other crap I’m running on this server. It crashed memory all over the place.

    • Ahh. I’ve played with APC, but never really used it extensively. DH has easy XCache support, so I just enabled that and it seems to work pretty well.

    • XCache isn’t friendly with MediaWiki all the time, and very much unfriendly with (again) this crap ass old bit of software I use ;) Which shall remain nameless cause it’s someone I host, not myself. :razz:

Half-Elf? Try Half OFF WordPress ebooks!