[Bug] open_basedir restriction (.user.ini) is ignored on websites using a public sub-directory (e.g., Laravel)

[Flabib]

Contact Information

No response

1Panel Version

v2.1.13

Problem Description

When deploying a PHP framework like Laravel, the website's document root (running directory) is typically set to the public sub-directory (e.g., /www/sites/mysite/index/public).

Currently, 1Panel generates the .user.ini file containing the open_basedir restriction inside the project root folder (/index/), instead of the actual document root (/index/public/).

According to PHP documentation, PHP only scans for .user.ini files starting from the directory of the executed script up to the web server's Document Root. It does NOT look at parent directories above the Document Root. Because of this, the .user.ini file placed in /index/ is completely ignored by PHP, causing the open_basedir protection to fail silently and leaving the server vulnerable to cross-site contamination.

Steps to Reproduce

1. Create a new PHP website in 1Panel.
2. Change the website's running directory (document root) to a sub-folder like public (standard Laravel setup).
3. Check the location of .user.ini. It will be located in the parent directory (index/).
4. Run a PHP script inside public/ to check ini_get('open_basedir'). It will return empty because .user.ini is ignored.

The expected correct result

When a user selects a specific sub-directory (like public) as the running directory:

1. 1Panel should place (or symlink) the .user.ini file inside that active web directory (e.g., index/public/.user.ini).
2. The open_basedir path inside it should be automatically adjusted to include the parent project root so the framework can function properly, for example: open_basedir=/www/sites/mysite/index:/tmp/

Related log output

Additional Information

No response

[wanghe-fit2cloud]

Thanks for your feedback. We will continue to optimize this in future versions.