Эта тема на forum.dklab.ru


Advanced Guest: Использование eval
Есть большой скрипт.
В нём порядка 50 файлов инклудится за запуск. Наборы файлов достаточно постоянные (порядка 10 наборов).
Есть мысль сохранять периодически их все в один файл и запускать оттуда eval-ом (отделять допустим один от другого /* filename */ и разбирать после считывания файла и запускать eval(данные) вместо шinclude(файл) ).
Скорость работы померяна, в том числе местными библиотеками, получился однозначно положительный эффект (порядка 50% прирост скорости).

Есть некоторые сомнения по поводу безопасности, навеянные многочисленными постами в форумах что хранить исполняемый код в файле с правами на запись плохая идея. Поэтому хотелось бы услышать на эту тему какие-то комментарии.
С одной стороны понятно что и register globals on и права на запись на файлы с кодом это как бы минус к безопасности. С другой стороны, если на хостинге оказался скрипт который смог записать что-то в такой файл, или это было проделано другим образом, то значит уже взломали и записывание другого кода в файл погоды не сделает?

Если есть ещё грабли - хотелось бы услышать.

Спасибо.
Юрий Насретдинов:
хранить исполняемый код в файле с правами на запись плохая идея
Это бред, если хостер нормальный.
Ksnk:
Юpий Насрeтдинов
Imho - не такой уж и бред. Представим себе 2-х клиентов этого самого хостера, один из которых так хранит свои скрипты, а другой "злонамеренно" ставит какой-либо WEB-файлменеджер у себя. При наличии минимальных знаний о структуре файловой системы хостера 2-й клиент легко может поправить скрипты 1-го, так как работа обоих клиентов идет все равно от имени юзера, запускающего PHP. Поправьте, если я не прав...
Юрий Насретдинов:
так как работа обоих клиентов идет все равно от имени юзера, запускающего PHP
Я же сказал - если хостер нормальный. А у нормальных хостеров Apache запускается именно от каждого конкретного пользователя, а не от одного и того же.
Ksnk:
так как работа обоих клиентов идет все равно от имени юзера, запускающего PHP
Я же сказал - если хостер нормальный. А у нормальных хостеров Apache запускается именно от каждого конкретного пользователя, а не от одного и того же.
А можно с этого места - немного поподробнее. imho, это несколько отличается от того, что я вижу в жизни и читал в мануале ;-)
Аппач запускается один раз и не перезагружается под каждого зашедшего клиента... Php запускается с правами Аппача. Где я не прав?
Юрий Насретдинов:
imho, это несколько отличается от того, что я вижу в жизни и читал в мануале
В мануале чёрным по белому написано, что апач работает от имени какого-то одного пользователя.

Аппач запускается один раз и не перезагружается под каждого зашедшего клиента...
А вот и нифига. Да, по умолчанию, апач на каждый запрос отдельно форкается от имени того же пользователя, что и у него. Но ничто не мешает немного подправить исходный код апача, и форкать от имени другого юзверя, что успешно и делают многие серьёзные хостеры, вместо того, чтобы запускать PHP в ужасном safe mode. А в остальном Вы правы
Ksnk:
Юpий Насрeтдинов
Насколько я в этом разобрался, видимо, все-таки не сам Аппач форкается, а PHP запускается с правами разных пользователей, в зависимости от адреса-назначения. так? Да, это разумно и , конечно, очень правильно... Но неужели это достигается только правкой кода вручную и перекомпиляцией? Есть ли более цивилизованные методы?
Евгений Галашин:
Есть ли более цивилизованные методы?
suexec. Или vds. Но в цивилизованности и того, и другого есть некоторые сомнения... (-:
Юрий Насретдинов:
PHP запускается с правами разных пользователей, в зависимости от адреса-назначения. так?
Так как обычно PHP работает как модуль апача, то ответ будет нет :). Именно апач форкается под другим пользователем
Ksnk:
Юpий Насрeтдинов
Эээ... Хм... да! Действительно.
Однако! Каждому юзеру по собственному аппачу!!! Вы действительно говорите про "нормальных хостеров"? :))) Так ведь несложно и кони двинуть, если очень много юзеров одновременно хостить... Впрочем, это я от общего недоумения...
Евгений Галашин:
Евгений Галашин писал(а):
Насколько я помню, я этого не писал(а)... (-;
Юрий Насретдинов:
Однако! Каждому юзеру по собственному аппачу!!!
См. что делает функция vfork

Насколько я помню, я этого не писал(а)... (-;
Ну, не там где надо нажал кнопку «Вставить»... Подумаешь...
Ksnk:
См. что делает функция vfork

VFORK(2) Linux Programmer's Manual VFORK(2)
НАЗВАНИЕ
vfork - создает дочерний процесс и блокирует родительский
...

Экий, однако,злой хакерский трюк прямо в самом ядре :). Не мудренно, что его грозяться прибить в будущих релакциях Линукса, а авторы Аппача не решаются вставить в код.
Теперь понятно, vfork'нутая версия Аппача живет только до конца исполнения запроса, а затем завершается-возвращается обратно, практически без никаких дополнительных расходов!
Спасибо!
Юрий Насретдинов:
Не мудренно, что его грозяться прибить в будущих релакциях Линукса
Многие хостеры юзают FreeBSD, а их разработчики не страдают такой манией всё переделывать начисто каждые 3 года...
Дмитрий Котеров:
Скорость работы померяна, в том числе местными библиотеками, получился однозначно положительный эффект (порядка 50% прирост скорости).
Это ОЧЕНЬ странно. Вы уверены, что не ошиблись при замерах? Я пару лет назад тоже мерял, получилось практически одно и то же время работы, что так, что сяк. Особенно - если позапускать скрипт несколько раз, чтобы все прокэшировалось.
Advanced Guest:
Скорость работы померяна, в том числе местными библиотеками, получился однозначно положительный эффект (порядка 50% прирост скорости).
Это ОЧЕНЬ странно. Вы уверены, что не ошиблись при замерах?
Не уверен.
Изначально делался echo microtime(); в начале и конце скрипта, 100 запусков подряд скрипта со считыванием и обсчетом результата (другим скриптом).
Есть определённая доля вероятности что 50% вылезло по другим причинам, так как сам код для реализации такого способа менялся тоже, хотя и не сильно. Например file_exists все исчезли из кода, файлы не подключаются по нескольку раз (иногда инклуды делались не однократные), директории не читаются opendir-ом.
Дмитрий Котеров:
Тогда прежде, чем химичить с eval-ом и общим файлом, сделайте замеры и убедитесь на 100%, что это поможет.
Ибо на спичках не экономят.
Advanced Guest:
Тогда прежде, чем химичить с eval-ом и общим файлом, сделайте замеры и убедитесь на 100%, что это поможет.
Ибо на спичках не экономят.
Ок. Попробую убедиться. Любопытно стало даже.
Но с другой стороны если eval на безопасности отрицательно не повлияет, то какая разница из-за чего идёт прирост по скорости?
Просто сейчас реализация с eval-ом уже сделана, а переделывать обратно на файлы ох как не хочется:-)
Или есть разница?
Алексей Пешков:
eval() и include() делают одно и тоже -- исполняют код. Разницы нет (исключая мелочи, типа диагностики ошибок).
Advanced Guest:
eval() и include() делают одно и тоже -- исполняют код.
Тут выбор не между eval и include, а между fopen, fread, fclose, 50*eval и 50*inlcude

Эта тема на forum.dklab.ru