We are facing performance issues running wordpress sites (especially with large plugins such as woocommerce) on our ispconfig managed server. Before going into further details I want to note that the following is not a fault of ispconfig itself but related to php in general and the default php settings used with ispconfig. Out of the box ispconfig sets open_basedir for newly created websites. While having open_basedir in effect increases security it appears to negatively affect the performance of websites (obviously only of those using php). To quantify the impact of open_basedir on wordpress+woocommerce performance we measured the server response time (time to first byte) with and without open_basedir enabled and saw a significant increase in server response time with open_basedir enabled (see figure below). [environment: nested virtualization 4vcpu 4GB ram; freshly installed debian 12 with ispconfig; single website with php 8.2.13 php-fpm dynamic (all default)]. We don’t feel comfortable giving whatever is executed with php full access to the filesystem by disabling open_basedir in a shared hosting environment, but we would need a way to alleviate the negative performance impact of such security restriction(s). Would there be any viable alternatives to open_basedir? One option would be to run php-fpm chrooted but this will cause paths to change and thus most likely break already deployed websites with hardcoded paths and websites relying on information reported in $_SERVER. Any suggestions are welcome . no_basedir: open_basedir not in effect basedir: open_basedir in effect
Regarding paths in chroot, you could try to create symlinks for the old paths, basically you create a path + symlink like /var/www/clients/client1/web1/web => /web inside the jails plus the same for the domain based path. Regarding alternatives for open_basedir there are not so many technologies available for that in my opinion, maybe you can try something like SELinux or AppArmor.
Thank you Till - you are right fully replicating the domain based path in the jail should allow overcoming this problem. Do you see any problem with disabling open_basedir when running php-fpm in chroot jail?
There is one problem, though, the applications must use 127.0.0.1 for MySQL connection and not localhost, as localhost is a connection to the MySQL socket, which is not available in the jail.
A solution for the MySQL socket issue might be to mount it into the jail using bind-mounts. You just have to test if this survives a mysql restart as this will recreate the socket.
Thank you Till for sharing your assessment on running php-fpm chrooted without open_basedir. Thank you for also pointing out the missing mysqld.socket in jail. Yes you are right a bind mount will not survive mysqld restart, however, a small script executed with ExecStartPost from the mysqld service unit should allow to (re)create the bind mounts after mysql starts.
Just attempted to switch one of the wordpress installations over to chrooted php-fpm instead of open_basedir. Unfortunately it initially failed as php-fpm started segfaulting once chroot for php-fpm was enabled. I have created a new thread for this issue.
