Undocumented Feature of Pantheon.io Presents Security Vulnerability

During my first week using Panthion.io (hereunder referred to as ‘the pan’) I noticed another dev had committed some – – r files that were not readable in my environment, yet they still executed on the pan. (PHP doesn’t need executable permission, but the server user needs “read” permission.) I questioned Pantheon.io about this and to my surprise they admitted this is an “undocumented feature.”

Pantheon changes your file permissions without telling you it’s happening. Why is this bad? Maybe you intentionally did a “chmod” on some files expecting them to be private. But in reality, maybe a hacker is able to download or execute the file you wanted non-readable, or vice-versa. And who really knows, right? Because it’s undocumented.

To some degree, the whole pan is undocumented. That’s the nature of closed-source proprietary technology. I can just hear Matt Mullenweg groaning, “I wish the pan fell under our open source license :-(”

At first glance, changing permissions for us seems “user friendly.” Why should non-devs (the target market for Pantheon.io) worry about file permissions? After all, 80% of web server issues are due to permission problems.

But as we contemplate this a little more…hmm, this is potentially dangerous. It’s a completely undocumented “feature” or vulnerability if you think about it. I’m guessing because:

1. It presents a security risk. Kinda embarrassing. You would be telling hackers/thieves what the permissions are automatically changed to, and then Pantheon couldn’t just do a blanket chmod -R +755 or +644 or whatever to ‘fix’ the permissions of its technically-challenged users.

Pantheon presents a big target for hackers, because a vulnerability there could be exploited across every client, which includes Google.

2. The pan’s goal is to make life easier for an average agency to deliver advanced technology to clients they could not otherwise serve themselves because they lack the technical skill.

Exposing this permission issue (here we go now) will complicate life for a lot of junior people that have no idea how a production server works. Who is “www-data” and why should you care? Overlooking the complexity has repercussions beyond the scope of this post.

Simply put, if you’re in the business of publishing content for clients that trust you to know what you’re doing, you should have someone that knows what they’re doing.

Choosing a proprietary tool like Pantheon.io that obfuscates your responsibilities is bad for business. I’m no open source evangelist, but we must admit that mature open source software is usually very reliable and secure with few surprises. That’s why most of the Internet still uses a LAMP/LEMP stack, it’s predictable and documented.

Is Pantheon actually easier than using LEMP/LAMP directly?

No. In reality, the pan is more convoluted than using a LEMP/LAMP stack directly because you’re introducing another layer of complexity which results in technical limitations, unpredictable behavior like “undocumented features” (aka backdoors), common techniques/tools are unavailable, outgoing ports are randomized, and non-standard systems such as “Terminus” are necessary to “lock in” a business to the Panthion.io system, presenting an unnecessary challenge if Panthion prices rise, if the company goes out of business, is hacked, hit by a storm, has a disgruntled employee, or is acquired, etc.

And I’d say Pantheon.io is an acquisition target for some larger company like Amazon that is looking to get into the WordPress business (Amazon is quietly exploring this BTW.)

Another problem here, copying “dev” to “live” should only take a few seconds at the most. With Pantheon the workflow is quite complex and time-consuming, which makes rolling out changes take longer.

Because Pantheon aims to please the most demanding agencies, all Pantheon users end up doing things the most convoluted way possible, such as moving code through four stages from local > dev > test > live. And with Pantheon, each stage has its own weird quirks, like on the dev server you only have file “write” permissions in the uploads directory, and outgoing IPs are randomized so there’s no way to know if your blog has a blacklisted IP address that’s affecting your API integration, for example.

A skilled developer can safely move from “dev” to “live” with more agility, without spending days researching Pantheon’s limitations. So whatever time you think you gained not setting up a proper stack, you just lost it reading Pantheon documentation and looking for workarounds. And because your developer can’t just ssh into the server, you have vastly limited your capabilities. It’s likely you’ll need a 2nd server to do the things you cannot currently do on Pantheon.

Pantheon is advertised as “we save you time setting-up / managing tech.” In reality, Pantheon’s non-standard platform results in a lot more head scratching, like why can’t I do XYZ? Oh, that’s different in Pantheon, oh it’s blocked, oh check this URL for the long explanation of the convoluted way we do that in Pantheon.

Instead of learning the correct (albeit complex) way to develop WordPress, your agency on Pantheon is getting into a LTR with a proprietary system that has “undocumented features.” And in my experience, hosting platforms usually peak after a few years and sometime during the decline (usually it happens quickly) savvy publishers all flip their DNS to the next hip hosting company. If you’re not really sure how your existing server is setup, you may not be prepared to migrate out gracefully when that time comes.

If you would like real WordPress hosting from a real WordPress developer, let’s talk. Look me up on LinkedIn. I’m “PJ Brunet” and let’s connect there.