Может быть нужно чтение и исполнение на папку, где лежит скрипт, для проверки его наличия.
Я обычно делаю проверку вроде
if (-f $document_root$fastcgi_script_name){
http://www.yiiframework.com/doc/guide/1.1/en/quickstart.apache-nginx-config#nginx
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Chrooted php-fpm, как давать доступ нжинксу?
- Автор темы Фанат
- Дата начала
Я обычно делаю проверку вроде
if (-f $document_root$fastcgi_script_name){
http://www.yiiframework.com/doc/guide/1.1/en/quickstart.apache-nginx-config#nginx
MiksIr
miksir@home:~$
www-data добавляется в группу пользователя. У каждого пользователя своя группа, а www-data в нее входит. Это не дает возможности другим пользователям ходить друг к другу если нет прав other. Запретить пользователям сменить права на свою домашнюю директорию (что бы случайно 777 не поставили) можно chattr +i
Вроде было какое-то ограничение раньше на уровне libc на число групп, в которые может один пользователь входить, сейчас не знаю. Но в общем решается использованием ACL, которые почти везде нынче есть.
chroot - это в общем как дополнительный уровень "закрытия", который мало что дает, особо если пользователям дается ssh. Тогда уж лучше сразу в сторону lxc смотреть.
Вроде было какое-то ограничение раньше на уровне libc на число групп, в которые может один пользователь входить, сейчас не знаю. Но в общем решается использованием ACL, которые почти везде нынче есть.
chroot - это в общем как дополнительный уровень "закрытия", который мало что дает, особо если пользователям дается ssh. Тогда уж лучше сразу в сторону lxc смотреть.
так ведь шелл тоже может чрутить из коробки?
Да блин у меня и так контейнер. В двумя гигами памяти.
Куда там еще lxc - то?
Каким боком lxc для шареда?
погоди.
Ведь кроме пыхи нужникс должен еще сервить статику.
То есть, доступ к htdocs у него по-любому должен быть.
Ну тогда мы возвращаемся к вопросу, нафига козе баян с разными пользователями фпм.
MiksIr
miksir@home:~$
nginx-ом пользователь не управляет, конфиги его не правит. А на php может куда угодно по идее сходить. Опять же, php создает файлы, с которыми пользователю работать. Вот и получается, что много удобнее, когда php работает от пользователя.
ну, ну самое 7лавное - я же не могу расшарить нужникс и пых между контейнерами? И мне надо запускать их в каждом?
Если это не так, то идея имеет. А если надо в каждом свой веб-сервер, то понятное дело, что не работает
Вот здесь не надо ля-ля.
То-то в свое время придумывали SuPHP и прочие извраты. Оттого что прав слишком достаточно было, видимо
У меня есть ощущение, что ты путаешь nginx/php-fpm и mod_php. Забудь про DocumentRoot из апача.
root-ов может быть много, например http://pastebin.com/fWRjvPxH
php_htdocs для php-скриптов, static_htdocs для скомпилированных css и js,
а рядом еще общий wwwroot с юзерскими фотками на много гигабайт, и php-скрипты там не исполняются даже если их туда залить.
причем, при работе приложения на фреймворке с единой точкой входа document_root указывает на wwwroot, а при вызове отдельных php-скриптов - на папку php_htdocs
Ничего не мешает статику раздавать из одной папки, а php-скрипты исполнять из другой, и на эти папки поставить разные доступы. У nginx может вообще не быть права чтения php-скриптов.
Последнее редактирование:
Не обижайся.
Просто SuPHP - это конкретный костыль, его так называли даже те, кто им пользовался.
Получается, что одними правами не настроить, все-таки.
Вот возьмём пока для примера статику
Есть веб-сервер.
Он должен читать файлы сайта.
Это значит, что эти файлы должны быть доступны пользователю www-data.
Для этого есть только два пути:
Либо дать читать файлы сайта всем, либо добавить пользователя в группу веб-сервера и дать доступ на чтение группе.
Я правильно понимаю?
MiksIr
miksir@home:~$
Ну наверно я не так выразился. Под правами я имею ввиду разграничение доступа на уровне разных uid. Ясное дело, что тут должны быть разные uid. Этот вопрос и решают начиная от родного апачевского suexec-а и заканчивая нынешними пулами php-fpm.
Не пользователя в группу веб-сервера, а веб-сервер в группу пользователя.
Есть еще ACL, которым просто можно дать веб-серверу права чтения.
Есть еще всякие другие способы, которые идут уже в обход стандартных прав доступа, но редко используются.
Шаред уже давно не развивается, по-этому все решения в общем стары и колеблются между двумя крайностями: с одной стороны апач+mod_php под юзером веб-сервера и кучей патчей, что бы php скрипты не лезли к чужим, и с другой стороны - все под uid пользователя включая апач.
Ну, середина, которая чаще всего встречается - дать веб-серверу, который обслуживает статику, читать всех, а все исполняемое пользователем - под его uid. Так как веб-сервер - достаточно доверенная среда и пользователь почти не может влиять на него - получается достаточно секьюрно (хотя свои подводные камни есть, например, символьные ссылки, которые приходится отключать).
MiksIr
miksir@home:~$
Один из вариантов, да. Но нужно будет обеспечить, g+s, а его пользователь может легко сбить. А если собъет - то сам он группу не поменяет. По-этому, особо распространения на шареде не получило.нет,
ты можешь выставить у папки группу www-data, но владельцы папок в этой группе состоять не будут,
в группе www-data будет только nginx, который будет читать все папки
@Фанат, чота ты все усложняешь на пустом месте
Пусть у нас тупо пользователи user1 и user2 с одноименными группами, у них сайты в /home/user%d/www/%s (user_id, domain_name), каждому запущено по fpm в чрутах в /home/user%d. Файлики с умолчальным umask 022 будут rw-r--r--, то есть с правами на чтение - так что nginx спокойно их прочитает, с банальным root /home/user%d/www/%s. А fpm-у (для которого корень /home/user%d) передаем
fastcgi_pass /home/user%d/var/tmp/php-fpm.sock;
...
fastcgi_param DOCUMENT_ROOT /www/%s;
fastcgi_param SCRIPT_FILENAME /www/%s/$script_name;
...
Ну и всё, типа.
Пусть у нас тупо пользователи user1 и user2 с одноименными группами, у них сайты в /home/user%d/www/%s (user_id, domain_name), каждому запущено по fpm в чрутах в /home/user%d. Файлики с умолчальным umask 022 будут rw-r--r--, то есть с правами на чтение - так что nginx спокойно их прочитает, с банальным root /home/user%d/www/%s. А fpm-у (для которого корень /home/user%d) передаем
fastcgi_pass /home/user%d/var/tmp/php-fpm.sock;
...
fastcgi_param DOCUMENT_ROOT /www/%s;
fastcgi_param SCRIPT_FILENAME /www/%s/$script_name;
...
Ну и всё, типа.
Последнее редактирование:
это все классно, пока юзерам не нужна разделяемая системная библиотека.
Фанат это может даже помнить, если обращал внимание, при нем было
админ несколько дней трахался, собирал нам openssl под чрутом чтобы можно было делать запросы к API, подписанными нашим сертификатом,
он под чрут нам половину системных библиотек захардлинкал или собрал ручками
Фанат это может даже помнить, если обращал внимание, при нем было
админ несколько дней трахался, собирал нам openssl под чрутом чтобы можно было делать запросы к API, подписанными нашим сертификатом,
он под чрут нам половину системных библиотек захардлинкал или собрал ручками
Последнее редактирование:
может, там юзерам вообще не нужны ни курл, ничего, и все будет просто работать.
это у меня всегда что-то не так. в каждом проекте у меня segfault в php, критические баги в фреймворке, разный план исполнения запроса в разных минорных версиях базы, я уже даже не пытаюсь локально ставить php из репозиториев, сразу в debug mode собираю чтоб core dump был,
а люди годами работают, и никаких проблем
это у меня всегда что-то не так. в каждом проекте у меня segfault в php, критические баги в фреймворке, разный план исполнения запроса в разных минорных версиях базы, я уже даже не пытаюсь локально ставить php из репозиториев, сразу в debug mode собираю чтоб core dump был,
а люди годами работают, и никаких проблем