Re: чтение чужих файлов: не стоит патчить

[Gena Makhomed <gmm@xxxxxxxxx>]

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 mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru