Fix #76359: open_basedir bypass through adding ".."

[cmb69]

We explicitly forbid adding .. to open_basedirat runtime.

---

Note this is only a minimal fix for the reported issue. There are still problems with .. somewhere in the path, e.g. consider:

+---foo
|       oh.no
|
\---wwwroot
    |   index.php
    |
    \---foo
            no.problem

with index.php:

<?php
chdir(__DIR__);
ini_set('open_basedir', __DIR__);
chdir("./foo");
ini_set('open_basedir', ini_get('open_basedir') . PATH_SEPARATOR . "../foo");
chdir("..");
chdir("../foo");
var_dump(scandir(".")[2]);

outputs:

string(5) "oh.no"

Generally disallowing .. in the path might by too much of a BC break, though.

[cmb69]

It was actually my intention to target PHP-7.4.

[mvorisek]

ini_set('open_basedir', ini_get('open_basedir') . PATH_SEPARATOR . "../foo");

What is the impl. issue with this?

It should be possible to normalize the set value before it is used in the check and then when the fixed value contains .. the path must be rejected.

[cmb69]

It should be possible to normalize the set value before it is used in the check and then when the fixed value contains .. the path must be rejected.

That would be a behavioral change. As it is, relative paths, and absolute paths containing . or .. are added as is to the setting. Especially, . is even documented to work this way.

[mvorisek]

Then simply store the unnormalized path (if check passed of course) :)

[cmb69]

Then simply store the unnormalized path (if check passed of course) :)

That's what we're doing. But relative paths depend on the CWD, which might change later.

[1265578519]

https://bugs.php.net/bug.php?id=76359

看了一眼居然是三年前就捅出来的问题。。。目前才修复吗