Заставляем совместно работать open_basedir + realpath_cache

[turone]

Ещё бы показательно было насколько помогло — была задержка такая то, теперь такая то, интересует эффективность расширения на вашем примере.

[romy4]

Вот на примере Друпала показательней всего, для чего так необходим realpath_cache. Плюс уменьшение cpu load и обращений к диску даже на небольших проектах, когда их много, в сумме даёт прирост производительности.

[nitso]

Странное чувство не покидает меня после прочтения этой статьи.

Баг относится во-первых еще к версии 5.2, а во-вторых к включенному режиму safe_mode. Safe_mode выпилили еще пару лет назад (в 5.4 [раз] [два]). А вы рассказываете про решение этого бага в 5.6. Каша какая-то.

[b1rdex]

Если задан open_basedir, то кэш тоже не работает. Насколько я понял, автору необходима эта настройка + кэш путей.

[nitso]

Меня смущает только то, что во всех найденых упоминаниях этого бага присутствует safe_mode. А основной задачей указанного в статье модуля является возвращение safe_mode в последние версии php: «This version adds support for safe_mode = on setting.»

[romy4]

Нет, задача стояла убрать постоянные обращения lstat в проверке путей мимо кеша realpath_cache. То, что он может включать safe_mode — это уже побочные фичи. Главное, что свою задачу он решает. В багрепорте Safe_mode упоминается лишь потому, что он оказывает такое же влияние на realpath_cache, как и open_basedir.

[nitso]

Перепроверил еще раз — при включенной опции 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)

[romy4]

Не, идёт речь не про вызов php обёртки lstat, а именно системный lstat(), который наблюдается в логе strace.

[FractalizeR]

Кстати, вот тут есть объяснение, почему это до сих пор не «пофиксили».

[romy4]

Если честно, то странное объяснение. Open_basedir не даёт 100% гарантии, что юзер не откроет каким-то способом файл за пределами ограничений open_basedir. Остаётся вопрос, зачем вы тогда вообще сделали такую опцию? В общем, внятного ответа, почему не хотят исправить баг нет.

[FractalizeR]

Open_basedir не даёт 100% гарантии, что юзер не откроет каким-то способом файл за пределами ограничений open_basedir

Можно поподробнее? Что вы имеете ввиду?

[romy4]

Только то, что написано по вашей ссылке в комментарии: «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, если каким-то образом решится аспект безопасности (наверное, про изменения вне кеша).

[FractalizeR]

Он имеет ввиду, что если сделать так, как предлагает этот реквест, то open_basedir перестанет иметь смысл, поскольку будет небезопасен.

[FractalizeR]

удалено