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

Tue Apr 25 08:08:37 -05 2023

Hello,

I have only been following this discussion on the sidelines.
But today I had an experience with Shopware and I am definitely for a switch open_basedir = off in the GUI.
We had the problem with a Shopware instance with really many plugins (mod ruid2) that the page took ~ 2000ms to start rendering and that the CPUs had a lot to do all the time.
Switching off Shopware plug-ins did help a bit. But we were able to undo all that after I added in the site<nr>.include:

php_admin_value open_basedir none

The wait time immediately went down from ~ 2000 ms to ~ 500 ms.
So Shopware apparently responds extremely poorly (under certain circumstances) to open_basedir.

Best regards
Dirk

blackpoint GmbH – Friedberger Straße 106b – 61118 Bad Vilbel 

-----Ursprüngliche Nachricht-----
Von: Blueonyx <blueonyx-bounces at mail.blueonyx.it> Im Auftrag von Tobias Gablunsky
Gesendet: Mittwoch, 5. April 2023 13:38
An: BlueOnyx General Mailing List <blueonyx at mail.blueonyx.it>
Betreff: [BlueOnyx:26074] Re: BlueOnyx Webserver Performance a.k.a. the impact of "open_basedir"

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
> 

_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20230425/83a9065a/attachment.p7s>