Hello!

On Sat, Jan 15, 2011 at 12:52:57AM +0600, Pavel V. wrote:

> Здравствуйте, Peter.
>
> Вы писали 14 января 2011 г., 21:03:04:
>
> > 3. что воркер может читать и отдавать клиенту логи воркеров --- проблема
> > небольшая, потому девелоперам nginx пока и не с руки заниматься по
> > имплементационным соображениям, оно и понятно, ибо не для массового хостинга
> > ветка 0.х задумывалась, а для внутриконторских девелоперов, к которым, как
> > минимум применим уже орг. ресурс.
>
> Еще раз сакцентирую внимание: дело не только в логах.
> Пользователь foo с неким сайтом в /web/foo/sites/foo.com/htdocs легко может
> предсказать наличие файла пользователя bar в каталоге
> /web/bar/sites/bar.org/htdocs/index.php , сделать на него симлинк
> командой "ln -s /web/bar/sites/bar.org/htdocs/index.php
> /web/foo/sites/foo.com/htdocs/static/file.txt" и запросить его
> содержимое по адресу http://foo.com/static/file.txt . Получить
> пароли/исходный текст/ и т д.
>
>
> >> А решение есть уже давно:
> >> http://www.lexa.ru/nginx-ru/msg14919.html
> >> (Описание: http://www.lexa.ru/nginx-ru/msg14850.html )
>
> > а что, запрещение FollowSymLinks не сделано? в любом случае, это не решение.
>
> FollowSymLinks - это апач. В нем даже есть FollowSymLinksIfOwnerMatch.
> Но мы говорим про nginx, и он по-умолчанию отдает(обрабатывает) файлы по ссылке.
> Тот патч из рассылки как раз таки делает FollowSymLinksIfFileIsUnderDocRoot.
>
> Так что, хотелось бы увидеть более развернутый ответ на эту тему,
> побольший, чем "в любом случае, это не решение". Новое узнавать
> интересно/полезно.

Развёрнутый ответ про симлинки какой-то такой:

Защита от symlinks сейчас отсутствует во всех http-серверах, ибо
сделать ещё правильно можно только через системный вызов openat()
либо на уровне операционной системы (mount -o nosymfollow).

Применяемый в apache и lighttpd lstat() - это плацебо, там race
condition между проверкой по lstat() и реальным открытием файла.
То же относится к патчу по ссылке выше.

Если кому-то не лень - можно сделать правильную проверку через
openat(), благо он попал в POSIX и стал появляться во всяких
операционных системах. Но надо при этом понимать, что тут ещё и
performance tradeoff, минимум один системный вызов на каждый
компонент пути, т.е. без реальной нужды это так или иначе
использовать не рекомендуется, а в случае реальной нужды - mount
-o nosymfollow будет дешевле.

Развёрнутый ответ про патч от Гены, оставляющий только chmod +w
вместо chmod +rw какой-то такой:

Я считаю патч в целом правильным, но недостаточным. С этим местом
есть более одной проблемы. В частности - если файл уже создан
заранее и проставлены достаточные для nginx'а права, но через
group permissions, - nginx полезет owner'а менять без нужды. Надо
туда посмотреть внимательно.

Идеальное решение (передавать открытый дескриптор из мастера)
понятно, но нетривиально в реализации.

Maxim Dounin

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru