Fix #65069: GlobIterator incorrect handling of open_basedir check #9120
Conversation
bukka
force-pushed
the
glob_wrapper_open_basedir
branch
3 times, most recently
from
ec34cfa
to
d96c168
Compare
|
So after a bit of thinking I went for solution with empty array as it is really the only one that makes sense to me. |
bukka
force-pushed
the
glob_wrapper_open_basedir
branch
from
d96c168
to
960d127
Compare
|
Will/can this PR address also https://3v4l.org/EYVGd? |
bukka
force-pushed
the
glob_wrapper_open_basedir
branch
from
960d127
to
f03676c
Compare
|
@mvorisek This PR is just for glob wrapper (glob://... or GlobIterator that uses that) so I don't think it can address the issue you mentioned. From a quick look, I'm not sure why this actually doesn't work as it is under /in but haven't checked the code. Even if it is supposed to be like that, it might be worth to create a separate issue for it because it might be at least a documentation issue. Can you check if there is already a bug for this by any chance? |
|
bukka
force-pushed
the
glob_wrapper_open_basedir
branch
from
f03676c
to
7953a39
Compare
bukka
force-pushed
the
glob_wrapper_open_basedir
branch
from
7953a39
to
76eb3ba
Compare
|
@cmb69 I saw your comments in the related PR https://bugs.php.net/bug.php?id=77085 so it would be great if you could have a quick look. I target master as there is that potential minor BC break that you mentioned in that bug for glob function. I would actually like to introduce the same behavior for glob as it just doesn't make sense to do open basedir check on pattern. I think it should be still fine for beta. What do you think? |
bukka
force-pushed
the
glob_wrapper_open_basedir
branch
from
76eb3ba
to
3235c92
Compare
|
Merged via 1a9e689 |
Proper checking and filtering of glob stream paths when open_basedir set.
This is a rebase with some minor changes of PR #398 that I did 9 years ago that got somehow sidetracked discussion about the correct glob behavior. After thinking about this, the PR still makes sense to me as it fixes the reported problem even though it doesn't do anything about the inconsistency which is however already present in glob so there is no reason to not apply this.