[BlueOnyx:26074] Re: BlueOnyx Webserver Performance a.k.a. the impact of "open_basedir"

[Tobias Gablunsky]

Hi Michael,

thanks again for further diving into it.

I think there are no big differences in our testing setups, but yes we are using the fpm php implementation.

When it comes to the security impacts of disabling open_basedir on a Wordpress installation I totally agree with you. But in our case we have to find a way to speed up the website. And the bottleneck in our case for sure was the deactivated "realpath cache" which lead to many, many more file accesses.

So I would really like to have both: security and performance. That's why we will try to compile the mentioned PHP extension (https://github.com/Whissi/realpath_turbo), so that it works with your current php versions. 
Of course we have to disable any php functions that are able to create symlinks as well - as mentioned on the extensions page. As far as I can see this already is the case: shell_exec and escapeshellcmd are disabled by default (link and symlink are disabled by the extension itself).
And there is another needed restriction mentioned: no enabled shell access for users. But we can assure this on our systems as well. 

I know this extension didn't get changed in the last 3 years. But: the code itself is quite short - so maybe there haven't been issues since the porting to php 8. At least Remi Collet, a maintainer of an own well known php repository has included this extension. We have enabled this repo on some other systems of ours already.

So I really think the risk is acceptable in our case.

Kind regards,
Tobias

-----Ursprüngliche Nachricht-----
> Von: Michael Stauber <mstauber at blueonyx.it>
> Gesendet: Montag 3. April 2023 18:10
> An: blueonyx at mail.blueonyx.it
> Betreff: [BlueOnyx:26063] Re: BlueOnyx Webserver Performance a.k.a. the impact of "open_basedir"
> 
> Hi Tobias,
> 
> > thanks for looking into it. I was really suprised by your perfomance 
> > measures. But I found there is a difference in commenting out the 
> > open_basedir option and disabling it by setting it to the value "Off". 
> > When disabling the php process gets the server wide setting, which isn't
> 
> > off.
> 
> You're right. I just tested it with a <? phpinfo(); ?> page in the Vsite 
> where I had commented out open_basedir. It was then indeed using the 
> server wide defaults.
> 
> > Please repeat your test with "php_admin_value[open_basedir] = Off". I am
> 
> > sure you will see the difference.
> 
> Done. Same setup as before.
> 
> A "naked" standard template Wordpress Vsite with open_basedir disabled 
> loads around 25-30 milliseconds faster. The one with open_basedir takes 
> 1.3s to load, the one without needs around 1.00-1.05s to load.
> 
> It's still not *that* much of a difference, especially considering that 
> the standard Wordpress template need around 0.340-0.355 seconds to just 
> load its SourceSerif4Variable-Roman.ttf.woff2 font.
> 
> > The website I just tested (a real 
> > world wordpress with lots of content and plugins installed) just took 5
> 
> > seconds before and less than 1 second after the change..
> That is interesting and it sure is a difference. It made me curious 
> enough to use a real life example as well: www.blueonyx.it
> 
> It's not using Wordpress, but a CMS system that is equally (but not 
> quite) as bloated as Wordpress. I switched the PHP implementation to 
> suPHP to have an easier time to fiddle with the php.ini
> 
> First test:
> 
> Made sure with phpinfo() that it was set to our Vsite defaults.
> 
> Load times? Varied between 3.10-5.81. The worst I got was 8.01s.
> 
> Second test:
> 
> open_basedir = off
> 
> Made sure with phpinfo() that it was reporting "no value"
> 
> Load times? Also all over the place. The worst I got was 10.87 seconds, 
> followed by a 10.02 seconds, but usually between 2.61 seconds and 3.67 
> seconds. Best I ever got was 2.42 seconds.
> 
> Like said: This was with suPHP and we usually use DSO+mod_ruid2 for that 
> Vsite. Couldn't try PHP-FPM, as that would have impaired a certain 
> functionality of the site.
> 
> So does open_basedir have a discernible impact? I'm leaning towards yes 
> and I agree that the severity of the impact has something to do with the 
> code quality and complexity and that also implies that Wordpress sure 
> may be affected stronger than most other applications. Especially with 
> respect to its modularity, which requires more include calls the more 
> modules are active.
> 
> Would I be comfortable turning open_basedir off on a Wordpress site? My 
> personal answer to that would be a definite and emphatic "HELL NO!!!", 
> just because what a piece of often exploited hot garbage Wordpress is. 
> Its incredibly large market share makes sure that it gets a lot of 
> attention and every tiny fault or code error in Wordpress or its many 
> popular modules are quickly identified and exploited by a plethora of 
> different attackers. Turing open_basedir off on a Wordpress site is just 
> making it much easier for an attacker to reap more benefits from his hack.
> 
> On the other hand: I understand that we may need to allow people to make 
> their own informed decisions and that there may be scenarios (good 
> backups, server just used for a single client/purpose) where the speed 
> increase and the associated greater risk are an acceptable risk.
> 
> And allowing "open_basedir" to be set to "off" via the GUI on a per 
> Vsite basis isn't too complicated of a change in the existing code.
> 
> So I'll be looking at that in the coming days and will let you know once 
> it's possible to do it.
> 
> -- 
> With best regards
> 
> Michael Stauber
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx
>