Question open_basedir and WordPress, general consensus needed, configured or none?

[SDGPete]

Server operating system version

Windows 2019/2014

Plesk version and microupdate number

18.0.52

Hi,

I'm looking to find out the general consensus with regards to open_basedir configuation when WordPress has been installed.

From experience, the standard/quality of programming varies from one plugin developer to another. For the most part, these developers code their plugins in a Linux environment, they make some coding provisions for other environments when it comes to file paths but it's generally not great. The knowledge of the WordPress codex also varies greatly between developers and they don't always stick to the recommended way of coding paths within WP.

I've seen sooo many responses within WP plugin forums telling the users of their plugins to set open_basedir to none within the users PHP configs as a remedy for fixing their poorly coded plugins. There's no doubt that setting open_basedir to none does speed up and increase performance of WP in a Windows environment, uses less server resources through wasted processing and it will allow the dodgy coding within plugins to work.

I know having open_basedir configured properly isn't the "be all and end all of security measures" and there needs to be correct permissions set up in the first place to prevent problems but it does go some way to helping the most easiest ways of traversing directories that a subscription shouldn't have access to.

Most of our clients (web design agency) are using our own in house CMS and so this doesn't apply to them, but we have a few who just use us for hosting and they use WordPress (usually designed by an external agency) that they self manage but their installations run like pigs. All sites are created within separate subscriptions. Those that self manage are created separate customer accounts within Plesk and the applicable subscriptions are assigned to those customers.

So I guess my questions are:

• How many of you are in similar scenarios?
• How many will set open_basedir to none?
• How confident are you of the permissions that Plesk sets within a subscription that the process worker for one subscription cannot access files of another subscription?
• Has Plesk ever made an official comment that it's safe/ok to do so?
• What other precautions (if necessary) would you take to help make it secure?

It would be great to get others opinions or facts about this so we can make a better informed decision.

Thank you!

 

[SDGPete]

Would be great to get Plesk's input on this too please.

 

[scsa20]

So... for open_basedir, it's more for prevention of accidental modification of the file system along with trying to help mitigate any effects of vulnerable PHP scripts against the file system. So if you can avoid it, I wouldn't just set open_basedir to none in a shared environment but likewise it wouldn't cause any issues either since you can't rely on it to actually protect you either (keeping your system fully up to date is truly the recommended way, along with a good AV).

As for the permissions, Plesk is really good at making sure that the permissions are good, but then again, IIS by itself is also good enough in general for the permission which is what Plesk leverage anyways along with making sure permissions are properly set.

 

[SDGPete]

Thanks for your input @scsa20 !

I guess another/the main question (to everyone) is if open_basedir was set to none, how easy would it be for someone to use PHP to explore outside of the subscription's root directory (i.e. inetpub/vhosts) and either navigate around directories belonging to other subscriptions or even go further and into other drives?

 

[SDGPete]

@Peter Debik and @IgorG apologies for tagging, I know you're busy guys but it would be great to get your perspective on this please.

 

[Peter Debik]

For security sensitive websites you need your own server or cloud instance or CageFS based on Cloudlinux. open_basedir slows operations down and can be circumvented to some extent. Nevertheless it is best to have as much security in place as possible. Also make sure that all the dangerous PHP feature by which users could execute operating system operations are disabled.

 

[Duarte N]

We set it to "none".

The "open_basedir" is placed in the ".php.ini" file at the root of the website (!), that is, if the website is hacked they have access to the file and they can remove this limitation, therefore, in practice it is of little use (like @scsa20 explained).

If you want to guarantee security, put each website under a subscription that is not shared by any other website:
From what I understand, permissions in Plesk are defined at the subscription level. In other words, even if each website runs in its own dedicated application pool, all application pools in the same subscription run with the same user. We return to the same thing: if a website is hacked, the hacker can reach all websites that are in the same subscription because all folders have read and, quite possibly, write permissions for the user running the app pool.

Consequence: Only websites that are under another subscription (whether from the same client or another client) are "truly" secure.

Plesk should consider, as others already do, creating a unique user for each application pool and defining website access permissions only for that user.