Comments 14
Ещё бы показательно было насколько помогло — была задержка такая то, теперь такая то, интересует эффективность расширения на вашем примере.
Если задан open_basedir, то кэш тоже не работает. Насколько я понял, автору необходима эта настройка + кэш путей.
Меня смущает только то, что во всех найденых упоминаниях этого бага присутствует safe_mode. А основной задачей указанного в статье модуля является возвращение safe_mode в последние версии php: «This version adds support for safe_mode = on setting.»
Нет, задача стояла убрать постоянные обращения lstat в проверке путей мимо кеша realpath_cache. То, что он может включать safe_mode — это уже побочные фичи. Главное, что свою задачу он решает. В багрепорте Safe_mode упоминается лишь потому, что он оказывает такое же влияние на realpath_cache, как и open_basedir.
Перепроверил еще раз — при включенной опции open_basedir
realpath_cache_size() действительно возвращает ноль. Не могу никак найти обработку open_basedir в контексте realpath_cache в исходниках. Однако, если вы говорите о lstat как о функции PHP, а не о системном вызове
По выводу
realpath_cache_size() нельзя делать выводы о кэше lstat() (и stat()), потому как для них реализованы два разных механима кэширования (в исходнике clearstatcache видно более наглядно). Вызов lstat() и без open_basedir не помещает значений в кэш realpath. Короткий тест на корректное функционирование кэша lstat:<?php
// обновляем mtime временного файла текущей датой
touch("./tmp");
var_dump(lstat("./tmp")["mtime"]);
// обновляем mtime "задним числом"
touch("./tmp", 1347062644);
var_dump(lstat("./tmp")["mtime"]);
// очищаем кэш и проверяем результат
clearstatcache();
var_dump(lstat("./tmp")["mtime"]);
$ php test.php int(1447062787) int(1447062787) int(1347062644)
$ php -dopen_basedir="." test.php int(1447062797) int(1447062797) int(1347062644)
Не, идёт речь не про вызов php обёртки lstat, а именно системный lstat(), который наблюдается в логе strace.
Кстати, вот тут есть объяснение, почему это до сих пор не «пофиксили».
Если честно, то странное объяснение. Open_basedir не даёт 100% гарантии, что юзер не откроет каким-то способом файл за пределами ограничений open_basedir. Остаётся вопрос, зачем вы тогда вообще сделали такую опцию? В общем, внятного ответа, почему не хотят исправить баг нет.
Open_basedir не даёт 100% гарантии, что юзер не откроет каким-то способом файл за пределами ограничений open_basedir
Можно поподробнее? Что вы имеете ввиду?
Только то, что написано по вашей ссылке в комментарии: «An open_basedir feature that doesn't actually guarantee that users can't open files outside of the specified base directory isn't useful.» Короче, я не очень понял Расмуса с его объяснением. Ну да, нельзя гарантировать, что файл не изменится, пока путь будет в кеше (это очевидно). Он типа не видит смысла в open_basedir, если каким-то образом решится аспект безопасности (наверное, про изменения вне кеша).
удалено
Sign up to leave a comment.
Заставляем совместно работать open_basedir + realpath_cache