Re: чтение чужих файлов: не стоит патчить
Gena Makhomed
gmm на csdoc.com
Вт Ноя 29 11:07:50 UTC 2011
On 29.11.2011 0:45, Peter Vereshagin wrote:
>> проблема в том, что таким образом любой сайт на shared hosting`е
>> может быть легко/тривиально превращен в источник внедоносного кода,
>> вирусов/троянов и т.п. - в самых тяжелых случаях пользователю вообще
>> не надо ничего запускать, достаточно просто открыть сайт в браузере,
>> и все - его локальная машина уже будет заражена вирусами/троянами,
>> и уже у пользователя будут воровать коды банковских карточек и т.п.
> Как будто без Follow Symlinks If Owner Match на shared hosting и так нельзя
> положить источник ВНЕ ДОНОСНОГО кода... (=
а как, если php не может выйти за пределы своего домашнего каталога
из-за ограничения open_basedir, а запуск внешних программ запрещен?
http://ua.php.net/manual/en/ini.core.php#ini.open-basedir
единственный оставшийся способ - это через симлинки получить доступ
к чужим конфигам на чтение, если статика раздается через nginx.
(а зная все пароли из конфигов - дальше - это уже дело техники)
> а где написано что мол nginx предназначено для замены apache на shared hostings?
а где написано что nginx нельзя использовать на shared hosting ?
>>> А вообще, шареный хостинг не нужен, есть облачные платформы
>> какой-то беспредметный разговор получается.
> хотите предметы --- скипайте квоту аккуратнее. Что там про панельки было?
> Ключевое слово --- "в перспективе".
клиенты не готовы ждать несколько лет,
им сайт в интернете нужен был еще вчера.
>>> $shared_hosting === $apache_httpd
>> пока что конкурентов PHP нет и не наблюдается
> не наблюдается != нет
для того чтобы поставить знак '!='
необходимо привести хотя бы один контрпример.
а пока что их нет, и поэтому их и не наблюдается.
>> в плане возможности максимально плотно упаковать
>> разные виртуальные хосты на один физический сервер.
> выбор технологии (PHP или не PHP) как может быть связан с параметром 'отношение кол-ва доменов per сервер'?
не доменов, а сайтов. с динамически генерируемым контентом.
> и вообще, физические сервера не нужны, есть облака, рекомендую. (=
и это после того, как недавно все эти облака глючили одно за другим?
>> в результате - для каждого виртуального хоста всегда будет активен как
>> минимум один PHP-демон, который будет занимать и память
>
> Copy On Write уже отменили?
вот именно из-за 'Write' он и будет занимать память.
> а где написано, что мол nginx задуман для раздачи статики с shared hostings?
а где написано, что это запрещено делать?
>> тут ведь кроме отдельного экземпляра PHP для каждого пользователя -
>> надо будет внутри chroot`ов запускать и по отдельному экземпляру nginx.
> а они, вроде, всё равно мапятся все в один участок памяти по типу memory
> mapping, нет? если бинарники все в одних и тех же inodes сидят.
у них разделяемым между экземплярами будет только сегмент кода,
сегмент с данными будет уникальным для каждого экземпляра.
буфера опять же, будут занимать немало оперативной памяти.
> в этих ваших shared_hosting ради кол-ва абонов кол-во whistles& bells
> настолько велико, что устранять саму возможность всё равно бесполезно. Да и
> незачем, ведь там всё равно всё выложено в публичный доступ. Или кто-то
> забывает сей пункт вложить быдлоюзеру (кто ж ещё в наши дни пользует заведомо
> устаревшую услугу шареного хостинга) на подпись в SA?
зачем закрывать уязвимости - об этом я уже говорил, чтобы нельзя было
так легко и просто как сейчас превратить сайты на shared hosting`ах
в рассадники вирусов и троянов. и nginx может в этом помочь.
сейчас же - или не использовать nginx на shared hosting`ах,
или иметь проблемы с безопасностью у всех клиентских сайтов.
--
Best regards,
Gena
Подробная информация о списке рассылки nginx-ru