ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /var/log/nginx



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


 




Copyright © Lexa Software, 1996-2009.