[SOLVED] How to resolve open_basedir restriction in effect

Development
1

Can anyone help me figure how to resolve the issue causing the logs to fill with open_basedir restriction in effect?

Environment

  • MODX 2.8.5
  • PHP 8.2.4
  • Ubuntu 22.04.2 LTS
  • Plesk 18.0.49

Logs

The MODX Error Log shows

[2023-03-25 14:54:57] (ERROR @ /var/www/vhosts/domain.com/httpsdocs/core/components/phpthumbof/model/phpthumbof.class.php : 221) PHP warning: is_readable(): open_basedir restriction in effect. File(/assets/uploads/images/sea-4.jpg) is not within the allowed path(s): (/var/www/vhosts/domain.com/httpsdocs/:/tmp/)

Web hosting settings

  • Webspace root is /var/www/vhosts/domain.com.
  • Document root is httpsdocs.
  • PHP open_basedir is set to {WEBSPACEROOT}{/}{:}{TMP}{/} in the Plesk Dashboard.
  • phpinfo shows open_basedir Local Value /var/www/vhosts/domain.com/:/tmp/ and Master Value /var/www/vhosts/domain.com/:/tmp/.

Putting this together I conclude that the file /var/www/vhosts/domain.com/httpsdocs/assets/uploads/images/sea-4.jpg is actually within the allowed path /var/www/vhosts/domain.com/httpsdocs/.

Plesk documentation shows a resolution for the same symptoms but where the user is attempting to access a file that is outside the web root and tmp directories
https://support.plesk.com/hc/en-us/articles/115000278993-A-website-hosted-in-Plesk-is-not-accessible-open-basedir-restriction-in-effect

I tried updating the default PHP open_basedir value shown above to {WEBSPACEROOT}{/}{:}{TMP}{/}{:}/var/www/vhosts/domain.com/httpsdocs but this had no effect.

I changed MODX System Setting Core > phpThumb > phpthumb_allow_src_above_docroot to Yes but this had no effect (even with clearing the cache). Nor should it have any effect but I’m pulling at strings now.

Another strange element is that clearing the phpThumbOf cache directory results in the cached files being recreated - this suggests to me that the open_basedir restriction report could be entirely incorrect.

The file owner is domain.com_sdkjfnh psacln which is the user the website runs under in Plesk. I reset the file and directory permissions as described below, also to no effect.
https://support.plesk.com/hc/en-us/articles/213910345-How-to-restore-default-permissions-in-virtual-host-directory-on-Plesk-for-Linux-

I know changing PHP open_basedir to none would prevent the error but that seems like a security risk and doesn’t explain why the cache files are created regardless of the error.

Can anyone suggest what I need to look at to resolve this please?

2

What extra are you using (pThumb or phpThumbOf) and what version?
I somehow can’t find a call to is_readable() on line 221 in either of them.

You could try adding an @ (the Error Control Operator) in front of the is_readable() call to suppress the warning.

3
  • pthumb 2.3.0-pl
  • Resizer 1.0.2-beta

System Settings for the phpthumbof Namespace have Use Resizer set to No.

In the file core/components/phpthumbof/model/phpthumbof.class.php : 221 line 221 is

if (is_readable($src)) {  // if we've already got an existing file, keep going

Suppressing the warning would be useful to prevent the Error Log from filling up.

Looking at this again I was beginning to think the issue may relate to the filenames uploaded by my client. I notice now that many include special characters eg. some starting with ' and others with & in the middle eg.

[2023-03-26 11:26:16] (ERROR @ /var/www/vhosts/domain.com/httpsdocs/core/components/phpthumbof/model/phpthumbof.class.php : 221) PHP warning: is_readable(): open_basedir restriction in effect. File(/assets/uploads/images/artists/john/prints/'After the Storm'51x51cms acrylic&canvas.jpg) is not within the allowed path(s): (/var/www/vhosts/domain.com/:/tmp/)

However files with proper filenames throw the same error

File(/assets/uploads/images/artists/john/prints/the-wave.jpg) is not within the allowed path(s

I’ll come back to this and set up a specific test Resource rather than working with the actual website which has tens of images per page, all added by my client.

4

So did you test changing the line to this?

if (@is_readable($src)) {  // if we've already got an existing file, keep going
5

Not yet. I was planning to get a wee test environment running and see if I can eliminate these filenames first.

A consideration for suppressing the error is the full size image is served where phpthumbof can’t perform the resize.

I’ll get another look after I clear some other tasks.

6

I did but there was no change, the error is still logged

[2023-03-25 14:54:57] (ERROR @ /var/www/vhosts/domain.com/httpsdocs/core/components/phpthumbof/model/phpthumbof.class.php : 221) PHP warning: is_readable(): open_basedir restriction in effect. File(/assets/uploads/images/sea-4.jpg) is not within the allowed path(s): (/var/www/vhosts/domain.com/httpsdocs/:/tmp/)

Next I created a simple test file /test/include.php with content

<?php include '/test/include_me.txt';?>

This also throws an error

PHP Warning: include(): open_basedir restriction in effect. File(/_dev/include_me.txt) is not within the allowed path(s): (/var/www/vhosts/domain.com/httpsdocs/:/tmp/)

Which accidentally led to identifying the resolution - this is a relative path which becomes $src in phpthumbof.class.php before being passed to is_readable() which triggers the error. As I understand the open_basedir values should allow the relative path to be located however it fails with the original error.

But we can change the value passed to is_readable() to an absolute path by setting &processTVs to true. I’m using pdoResources so the value I need is &processTVs='myImage'.

I am still unsure why the original setup failed when the server settings for open_basedir specifically allow {WEBSPACEROOT} to which the relative file path should be postfixed.

Or why the @ suppression in phpthumbof.class.php failed.

Also how this started with the error on line 221 which didn’t match your copy of the file, and after removing and reinstalling pThumb (which includes Resizer as a dependency) the error line changed to 238 (same function, just moved location in the file) - the system was up to date before I raised this query.