is_dir(): open_basedir restriction in effect

  • Resolved isarisar

    (@isarisar)


    2 years, 4 months ago

    Hi,

    since moving to a new hoster that actually enforces some version of the open_basedir restriction, we’ve been hitting that warning whenever a replace is executed:

    PHP Warning: is_dir(): open_basedir restriction in effect. File(/wp-content/uploads/{basename}) is not within the allowed path(s): ({list of dirs, incl. wp base dir}) in /srv/wp-content/plugins/enable-media-replace/classes/ <a href="https://github.com/short-pixel-optimizer/enable-media-replace/blob/master/classes/replacer.php#L472">replacer.php on line 472</a>

    Looking at the code, the issue seems to be from parse_url(…, PHP_URL_PATH) @ 465:

    PHP_URL_PATH will have parse_url always return a string starting with / – unless the URL contains no path at all, then it’ll return NULL – and this will be taken as prohibited absolute path (so starting from root, rather than wp’s base dir) to an open_basedir’ed is_dir().

    I guess the fix would be to prepend wp’s base dir, or just check for initial / and remove it from that string, like so.

Viewing 9 replies - 1 through 9 (of 9 total)
  • Thread Starter isarisar

    (@isarisar)

    IOW, just prepend the string with get_home_path().

    Dunno how well that works with installs that hide/redirect wp-content, though.

    Plugin Support Gerard Blanco

    (@sixaxis)

    Hi @isarisar,

    It sounds like your installation is not generating a full path for some images. Could you please check that with your hosting provider?

    Thank you!

    Thread Starter isarisar

    (@isarisar)

    Hi @sixaxis,

    what do you think about the part with parse_url(…, PHP_URL_PATH)?

    It is by definition not meant do generate full paths.

    See its PHP documentation, example 1 — PHP_URL_PATH is 3rd from bottom.

    So my hoster couldn’t possibly do anything about this.

    Plugin Support Gerard Blanco

    (@sixaxis)

    Yes, you are actually right, @isarisar.

    I’ll file a task in our to-do list so our team takes care of this. ??

    Thanks for reporting it!

    Plugin Author Pedro

    (@petredobrescu)

    hello @isarisar and thanks for reporting this!

    We added a fix that hopefully resolves the issue you have seen.

    Can you please either apply the fix or simply use the version from the updates branch of our GitHub repo and let us know if it works well now? I would strongly suggest you test this on a dev/staging copy because it’s a beta version of the upcoming 4.0 version that also comes with new features.

    Thanks, I look forward to getting your reply!
    Pedro

    Thread Starter isarisar

    (@isarisar)

    Hi @petredobrescu,

    thanks for the fix!

    Based on a straightforward replacement (no other options selected), the warning is now indeed gone.

    [Unrelated: There’s a “Remove after replace!” option at the bottom of the “Select Replacement Media” form. I’m afraid that option isn’t self-explanatory and so doesn’t tell the user what it will actually remove.]

    Thread Starter isarisar

    (@isarisar)

    Though looking at the code, the bugged check of the erroneous pathinfo call is still there, just “hidden” as second check in a new && evaluation:

    $base_url = str_replace('.' . pathinfo($base_url, PATHINFO_EXTENSION), '', $base_url);
…
if (strpos($abspath, $base_url) === 0 && is_dir($base_url))

    IDK if your dev knows more about how the function is called, but that means this check still could never work. Since that 2nd check would continue to fail with the original warning even if the 1st check comes true, the overall intended protection will never be effective.

    Plugin Support Gerard Blanco

    (@sixaxis)

    Hi isarisar,

    The check is there to prevent bad URLs from being fed to the replace function; the replace procedure would never start on a directory otherwise. Sometimes, on some botched WP images, the whole path is returned, so we are simply trying to prevent the replacing from happening then.

    I hope that clarifies it!

    Thread Starter isarisar

    (@isarisar)

    Ah, that makes sense then. Thanks!

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘is_dir(): open_basedir restriction in effect’ is closed to new replies.