Forwarded to devs Disabled PHP "Hosting performance settings management" can be bypassed by using .user.ini or ini_set()

[Hangover2]

Username:

TITLE

Disabled PHP "Hosting performance settings management" can be bypassed by using .user.ini or ini_set()

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian 18.0.61 Update #6, Debian 12.6, x86-64

PROBLEM DESCRIPTION

Even though we disallow the usage of adjusting the per-site PHP performance settings in our service plans, the clients can easily overstep that restriction by using a .user.ini settings file or the PHP command ini_set().

STEPS TO REPRODUCE

- Create a service plan and disable the permission for "Hosting performance settings management (Allows to adjust performance settings: Per-site PHP performance settings.)".
- Set some default PHP settings for performance and security in the service plan, e.g.:
memory_limit 512M
max_execution_time 60
- Create a subscription with this service plan.
- Create the file .user.ini inside the document root with the following content:

memory_limit = 2048M
max_execution_time = 240

- Create the file index.php inside the document root with the following content:

<?php
phpinfo();

- Open the website of the newly created subscription and check the output of phpinfo() concerning the values of memory_limit and max_execution_time .
- Instead of using the .user.ini file, you can also just put a single index.php file with the following content in the document root:

<?php
ini_set('memory_limit', '2048M');
ini_set('max_execution_time', '240');
phpinfo();

ACTUAL RESULT

- memory_limit is now 2048M
- max_execution_time is now 240

EXPECTED RESULT

- memory_limit should still be 512M
- max_execution_time should still be 60

ANY ADDITIONAL INFORMATION

This is a follow-up bug report from this discussion:
Disabled "Hosting performance settings management" is ignored when using .user.ini

In our case (dedicated PHP-FPM) a possible solution would be to use php_admin_value() for all performance and security settings when the permission to change them is not granted by the service plan in /var/www/vhosts/system/domain.example/etc/php-fpm.conf e.g.:

php_admin_value[memory_limit] = 512M

Instead of the current implementation:

php_value[memory_limit] = 512M

Disabling the .user.ini settings file or the PHP command ini_set() is no real option and would have too many side effects on our clients. The php_admin_value implementation seems to be the more suitable way.

Right now the whole feature has no real effect other than just disabling the graphical user interface in the admin panel. I think many Plesk users believe, that this feature protects them from over usage of server resources by their clients. But this is not the case. If this is an intended behavior, please fix the description in the service plans area. In that case please help sorting out, how we can restrict the server resources for use case mentioned. Shared hosting packages depend highly on that values concerning the package price and they should not be changeable by the clients.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[Kaspar@Plesk]

Submitted for analysis by engineers with ID: PPS-16342

 

[Hangover2]

I just read the changelog of the new Plesk Obsidian 18.0.63 release:

Added a note clarifying that PHP settings may be overwritten by those specified in the .htaccess, php.ini, and .user.ini files to the “PHP Settings” page. (PPPM-14505)

I hope this doesn't mean that the disabled "Hosting Performance Settings Management" for PHP is essentially obsolete and will not receive any patch. Right now, shared hosting packages are ineffective. One can simply purchase the cheapest web hosting package available from a Plesk hosting partner and raise the limits until even the most demanding CMS, framework or shop system will run.

 

[Kaspar@Plesk]

Based on your report we've decided to at least clarify the limitations of the current functionally. Other changes (including those suggested by you) are still being researched and discussed.

 

[Bitpalast]

One can simply purchase the cheapest web hosting package available from a Plesk hosting partner and raise the limits until even the most demanding CMS, framework or shop system will run.

A true dealbreaker, isn't it?

We've some surveillance on our servers here that I'm willing to share. Simply create a cronjob that auto-checks whether users use legitimate values and let that job run every few minutes, e.g.

/usr/bin/grep "php_value\[memory_limit\] = " /opt/plesk/php/*/etc/php-fpm.d/* | /usr/bin/grep -Ev "128M|256M|512M" 2>&1 | tee /opt/plesk/php/output.txt | mail -E -s "[NOTIFY] PHP-FPM using wrong RAM value" [email protected]

This would check whether there are accounts that modified the PHP RAM usage setting to anything different than 128M, 256M or 512M. If so, it mails you a list of these domains to [email protected].
A very simple, but at least for us here effective solution.

If you are seeking the user defined files, these will be easy to find by a "find" command, or they can be easily detected and analyzed by a simple shell script or PHP script. So if users try to circumvent limits, you'll find out.

From Plesk I am missing separate permissions that allow the service plan owner to lock certain PHP configuration fields, e.g. max runtime, max RAM usage etc., so that users must stick to what they purchased. Currently it's only possible by locking the whole PHP section.

 

[Kaspar@Plesk]

Hi all, I wanted to let you know that after some research we've decided to utilize the php_admin_value option for the PHP-FPM handler to prohibit certain PHP settings from being overwritten by end users. This solution only applies to PHP-FPM handlers, not to PHP-CGI or FastCGI handlers. As there is no option to prohibit PHP settings from being overwritten when any of these two handlers are being used.

There is no ETA yet on when exactly this fix will be implemented into Plesk.

Thank you @Hangover2 for bring this to our attention.