The Magic Sauce: Cloudfront IAM Policies for Use with W3 Total Cache

If you want to improve the performance of your WordPress installation, W3 Total Cache is one of the best options out there for optimizing page delivery and script minification. But if you want to take your performance web-scale, you’ll need to consider a commercial-grade Content Delivery Network (CDN). Fortunately, W3 Total Cache offer multiple options, and (in my humble opinion) Amazon Web Services Cloudfront running on top of an S3 bucket is the best CDN option available. While the W3 Total Cache FAQ has a decent overview of how to configure a basic CloudFront/S3 CDN, AWS architectures that implement the higher level of security offered by assigning specific IAM accounts to Cloudfront distributions and S3 buckets can present a problem.

Even though Frederick Townes deserves a Nobel Prize for creating W3 Total Cache, he didn’t quite nail it when comes to parsing messages generated by the AWS API when the plugin tries to connect to Cloudfront.

Here is the most common error messages I ran into when trying to configure W3 Total Cache to work with Cloudfront within a PCI 3 compliant AWS architecture:

Error: Unable to list buckets (S3::listBuckets(): [AccessDenied] Access Denied).

W3 Total cache tries to create a dropdown list of S3 Buckets to which the IMA account has access. While listBucket is a valid IAM policy to list the contents of an S3 bucketS3, listBuckets isn’t valid. The correct policy reference is ListAllMyBuckets.

The correct IAM policy should look like this:

"Statement": [
"Action": "s3:*",
"Effect": "Allow",
"Resource": [
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"

But this only covers the policy to list the S3 Buckets. If you’re using W3 Total Cache with Cloudfront, you also need to be able to list the Cloudfront distributions:

"Version": "2014-10-31",

From a security perspective, it’s not ideal that the IAM policy has to be able to list the distributions and buckets. A better solution would be to provide a field in which to manually enter the bucket or distribution name.

CHOWN IT – Change File Group Ownership to Solve WordPress Plugin Update Issues

chown-itIt happened again. When I logged into the WordPress dashboard, I saw that the NextGen Galleries plugin had a new update available. Updating WordPress plugins has become so routine that I take it for granted that pressing the magical “Update All” button will magically make my WordPress installation shiny and new. I can drink my coffee and watch plugin after plugin happily announce a successful update, one after another after another after another. And then NextGen Galleries takes a big dump all over my day with a “can’t delete directory” message.

As anyone whose worked on a few WordPress sites knows, WordPress is pretty finicky about file and user permissions, and setting file permissions incorrectly can break WordPress outright, or (more likely) open it up to being hacked. I typically follow the guidelines covered in the WordPres Codex article “Hardening WordPress,” but after verifying my file permissions were set correctly via my FTP client, and even after connecting to the server and running CHMOD against the directory and files, I was still getting the same “can’t delete directory” message.

After banging my head against the wall trying to figure out what was so “special” about my NextGen Galleries installation, I remembered that I had originally uploaded the plugin via FTP rather than via WordPress’ automatic plugin installer.

Even though my file permissions were set correctly, the “owner” of the files and directories was set to my FTP client account. To work properly, the files and directories needed to be owned by the same user and part of the same group as the web server (in this case an Apache server).

To fix my plugin ownership issues, I used my favorite SSH client, PuTTY, to connect to my Linux host server. After navigating to my WordPress “plugins” directory, I ran the following command:

 chown -R apacheusername:apachegroupname /path/to/wp-content/plugins/nextgen-gallery

In the example above, the “-R” flag tells chown to recurse the subdirectories and files.

This same technique works for themes, plugins and anything else WordPress needs to be able to write. Of course, the most important lesson to be learned from the “can’t delete directory” message is to install plugins and themes from inside WordPress whenever possible, and save yourself the headache.

For more information about how to use CHOWN, check out this article.