Interesting how events coincide. I wrote a bash script to tighten-down permissions on my shared hosted websites and within the hour I see a new Smashing Magazine article on Proper WordPress Permissions. You should read that if you haven’t done so already. Like pretty much everything Smashing does, it’s very good.
Here’s the backstory on why I created the script to strip WordPress permissions to the bare metal. I was using a hosting company for my WordPress sites I won’t name who had serious security shortcomings. My sites were getting hacked regularly. I took the appropriate measures to prevent as much hacking as I could, but the final straw was being greeted with a YOU’VE BEEN HACKED animated home page and every directory of every website with 755 permissions was gone.
It was time to move to a host I could trust, and so far I’ve been thrilled with Pair Networks. I was a Pair Networks client in the mid-90’s when we were both starting out. If I hadn’t experienced the Redmond Redirect I might have been with Pair for nearly 20 years. It’s never too late to make things right, and Pair is as awesome as I remember them. I honestly didn’t know they were still in business when I was looking for a Linux host or I would have gone with them sooner.
Back to the script and tightening down site permissions. The Smashing Magazine article recommends setting all files to 644, folders to 705 and the wp-config.php to 600 on shared server sites. I’m recommending folders set to 505 instead of 705 because I learned from my former Host from Hell that removing owner perms saved a lot of hacking heartache. 505 is probably overkill for Pair Networks, but lesson learned. The downside of going with 505 on folders is that WordPress automated updates will fail. That’s fine with me since I want to be the guy to click the update button anyway.
The script unlocks a site prior to performing a WordPress update. Then, after the WordPress update has completed, we run the script again to lock down the site. The IF – ELIF sections are probably backwords, because when first running the script we use the “–unlock” argument (shown in area 2) where we set the entire site folder structure to 705.
As for locking the site (area 1), we set all folders to 505, then add a 705 flag to only the folders that are used for support content that is frequently updated.
The script is run from the root directory above the individual WordPress sites. It requires two arguments, either “–lock” or “–unlock” and the folder containing the WordPress site we want to process. We’re reminded of the script argument requirements if we forget them.
A successful script execution looks like this.