Запуск сайтов на Nginx от разных пользователей

[STALKER_SLX]

Доброго времени суток, уважаемые форумчане!
Имеем такой стенд:
ОС Ubuntu 16.04 LTS,
Nginx 1.15 + PHP-FPM 7.x
и тестовый сайт на WordPress – «my-wp.loc»

Имя пользователя и группа, от которого запускаю новый pool веб-сервера для тестируемого сайта, – tester:tester
Внимание: Указанный пользователь и группа должны быть зарегистрированными (существовать) в ОС!

Сам веб-сервер работает от имени пользователя/группы – www-data:www-data (эти значения заданы в его основном конфигурационном файле – /etc/nginx/nginx.conf, т.к. первоначальная настройка Nginx проводилась согласно статьи – https://interface31.ru/tech_it/2016/04/nginx-php-fpm-debian-ubuntu.html)

В качестве отправной точки для решения поставленной задачи была взята вот эта статья – https://xakep.ru/2017/01/11/nginx-custom-config/

Вся иная, изложенная тут ниже информация, - собиралась мной на просторах Интернета по кусочкам и калькулировалась.


«При использовании Nginx доступ разграничивают, создавая отдельные PHP-FPM-пулы для каждого пользователя. Процесс при этом запускается с правами конкретного пользователя, и он будет без проблем редактировать свои файлы в FTP-клиенте, не рискуя, что кто-то еще может к ним подобраться».


1. Подключаем каталог с пулами в файле – /etc/php/7.0/fpm/php-fpm.conf, раскоментировав строку (если она отсутствует, то добавляем):
include=/etc/php/7.0/fpm/pool.d/*.conf

2. Переходим в каталог пулов:
cd /etc/php/7.0/fpm/pool.d/

3. Копируем конфиг для нового пула:
sudo cp www.conf pool2.conf

4. Редактируем конфиг нового пула:
sudo mcedit pool2.conf


[pool2]
listen = /var/run/php/php7.0-fpm-pool2.sock
# /var/run/ - это символьная ссылка на /run/php/, поэтому можно указывать и так и так

; Пользователь и группа, под которыми будет работать пул
user = tester
group = tester

; По умолчанию сокет работает под теми же учетками, что указаны в user/group, nginx должен его читать
; Иногда нужно использовать другие учетные данные
; Также следует убедиться что веб-сервер (или любой другой процесс, которому необходима коммуникация) имеет доступ на чтение/запись в ваш сокет.
; Для этого существуют настройки listen.group и listen.mode

; Проще всего - запускать оба процесса от одного пользователя или группы.
; В нашем случае php-fpm и веб-сервер будет запущен с группой "www-data":

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; Включаем отдельный лог для данного пула:
catch_workers_output = yes
php_admin_value[error_log] = /home/tester/fpm-pool2/p2-error.log
php_admin_flag[log_errors] = on

; Под планируемую нагрузку проставляем количество процессов
pm = dynamic
pm.max_children = 10
pm.start_servers = 3
pm.min_spare_servers = 3
pm.max_spare_servers = 6



5. В файле виртуального хоста «my-wp.loc.conf» изменяем сокет, после чего он будет выглядеть примерно так:
server {
    listen 80;
    server_name my-wp.loc;
    root   /var/www/html/my-wp/;
    index index.php;

access_log /var/log/nginx/my-wp.loc_access.log;
error_log /var/log/nginx/my-wp.loc_error.log;


# Включение ЧПУ (Support Clean URLs (aka Search Engine Friendly))
   location / {
      try_files $uri $uri/ /index.php?q=$uri&$args;
   }
# Подключаем нужные шаблоны с новым UNIX-сокетом
include /etc/nginx/templates/php-fpm-pool2.conf;
include /etc/nginx/templates/phpmyadmin-pool2.conf;

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param  SCRIPT_NAME $fastcgi_script_name;
        fastcgi_pass unix:/var/run/php/php7.0-fpm-pool2.sock;
    }
}
# Отдельно слушаем домен с www и редиректим его на основной
server {
  listen 80;
  server_name www.my-wp.loc;

  rewrite ^(.*) http://my-wp.loc$1 permanent;
}


6. Содержимое шаблона «php-fpm-pool2.conf» с новым Unix-сокетом:

location ~ \.php$ {
   try_files $uri =404;
   fastcgi_pass unix:/var/run/php/php7.0-fpm-pool2.sock;
   fastcgi_index index.php;
   include fastcgi_params;
   fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
}
#Запрещаем обрабатывать htaccess-файлы
location ~ /\.ht {
   deny all;
}
#Настройка кэширования статического содержимого
location ~* \.(gif|jpeg|jpg|txt|png|tif|tiff|ico|jng|bmp|doc|pdf|rtf|xls|ppt|rar|rpm|swf|zip|bin|exe|dll|deb|cur)$ {
  expires 168h;
}
#кэширование для скриптов и стилей
location ~* \.(css|js)$ {
  expires 180m;
}


7. Даем права доступа на сайт нашему пользователю (под которым работает новый pool2), то есть – tester:tester:
sudo chown -R tester:tester /var/www/html/my-wp/

cd /var/www/html/my-wp/
find . -type f -exec chmod 644 {} +
find . -type d -exec chmod 755 {} +


8. Включаем сайт sudo ln -s /etc/nginx/sites-available/my-wp.loc.conf /etc/nginx/sites-enabled/

9. Чтобы протестировать внесенные новые настройки PHP-FPM:
sudo php-fpm7.0 -t

10. Тестируем корректность настройки самого Nginx:
sudo nginx -t

11. Если тестирование прошло без ошибок, то перезапускаем PHP-FPM и Nginx:
sudo service php7.0-fpm restart      ----------# или же sudo systemctl restart php7.0-fpm
sudo service nginx reload                -----------# или же sudo systemctl restart nginx

12. Убеждаемся, что новый пул запущен правильно, запросив его процессы:
sudo ps aux |grep tester

В итоге новый пул заработал от пользователя «tester» и вместе с ним тестируемый сайт «my-wp.loc». Но, после проделанной работы у меня возник целый ряд вопросов.

1. Правильно ли я решил задачу (исходя из названия данной темы) или Вам знаком более оптимальный вариант? Если есть, то прошу подсказать «какой»?!
2. Безопасна ли указанная выше конфигурация для продакшн среды? Если нет, тогда прошу посильной помощи в "допиливании".
3. Нужно ли указывать в конфиге нового пула параметр «chdir =»?! Если нужно, то какое будет его правильное значение?
4. Как протестировать, что все ошибки ново-созданного «pool-а» пишутся в отдельный лог-файл (в данном случае – "/home/tester/fpm-pool2/p2-error.log")? Может, есть какой-то скрипт для этого?!
5. Правильно ли я понимаю, что владельцем папки и отдельного лог-файла должен быть пользователь, от которого мы запускаем новый пул? Если нет, то кто?

[Уваров А.С.]

cd /var/www/html/my-wp/
find . -type f -exec chmod 644 {} +
find . -type d -exec chmod 755 {} +

chmod -R u=rw,g=r,o=r,a+X /var/www/html/my-wp

[Уваров А.С.]

В итоге новый пул заработал от пользователя «tester» и вместе с ним тестируемый сайт «my-wp.loc». Но, после проделанной работы у меня возник целый ряд вопросов.

1. Вполне

2. Какая цель данной конфигурации? Запуск пула от имени другого пользователя в основном преследует цель разделить процессы на сервере между пользователями. Т.е. чтобы процессы пользователя А не имели доступа к процессам и данным пользователя B.

3. Зачем?

chdir string
Chdir изменяет текущую директорию при старте. Это значение должно быть определено как абсолютный путь. Значение по умолчанию: текущая директория или / при использовании chroot.

4. Уронить пул. Если честно, то ценность данного лога невелика,вероятность того, что вы уроните пул крайне низка, в отличии от вероятности ошибок в веб-приложении, которые пишутся в свой лог.

5. Нет, стандартно root:root

[STALKER_SLX]

2. Какая цель данной конфигурации? Запуск пула от имени другого пользователя в основном преследует цель разделить процессы на сервере между пользователями. Т.е. чтобы процессы пользователя А не имели доступа к процессам и данным пользователя B.

Совершенно верно, моя цель в данном случае - разделить процессы между пользователями!
Вы считаете, что указанных настроек будет достаточно для нормального и безопасного функционирования сервера, а также "невозможности" доступа к "чужим данным"?!

5. Правильно ли я понимаю, что владельцем папки и отдельного лог-файла должен быть пользователь, от которого мы запускаем новый пул? Если нет, то кто?

Тут немного некорректно выразился, я имел ввиду, что владельцем папки с сайтом должен быть пользователь, от которого мы запускаем ПУЛ.
Или таки, как Вы написали:

5. Нет, стандартно root:root

[Уваров А.С.]

Тут немного некорректно выразился, я имел ввиду, что владельцем папки с сайтом должен быть пользователь, от которого мы запускаем ПУЛ.

Ну так надо разделять сущности. Содержимое сайта - это пользовательские данные, владелец папки с сайтом - это пользователь пула, логи - это системные данные, их владелец - root.

[Уваров А.С.]

Совершенно верно, моя цель в данном случае - разделить процессы между пользователями!
Вы считаете, что указанных настроек будет достаточно для нормального и безопасного функционирования сервера, а также "невозможности" доступа к "чужим данным"?!

Если нигде не накосячите с выставлением прав - то достаточно. Если же выдать на папку с сайтом 777 - то тогда медицина бессильна.

[STALKER_SLX]

Содержимое сайта - это пользовательские данные, владелец папки с сайтом - это пользователь пула, логи - это системные данные, их владелец - root.

Вы ВСЁ верно написали! СПАСИБО!

Прошу Вас простить за мою поспешность и невнимательность! Я таки правильно указал в своем вопросе, что

5. Правильно ли я понимаю, что владельцем папки и отдельного лог-файла должен быть пользователь, от которого мы запускаем новый пул? Если нет, то кто?

А в комментарии ниже накосячил...

[STALKER_SLX]

логи - это системные данные, их владелец - root.

то есть, даже лог-файл "НОВОГО пула" должен иметь владельцем root:root?
Но ведь сам ПУЛ работает от другого пользователя - tester:tester, то как он будет записывать в папки/файлы, которые ему не принадлежат?!

[Уваров А.С.]

то есть, даже лог-файл "НОВОГО пула" должен иметь владельцем root:root?
Но ведь сам ПУЛ работает от другого пользователя - tester:tester, то как он будет записывать в папки/файлы, которые ему не принадлежат?!

Пул - это часть службы php-fpm, логи пишет служба, ее системная, а не пользовательская часть. Потому как пользователь к логам доступа иметь не должен, во избежания их удаления или изменения.

[STALKER_SLX]

Огромное Вам СПАСИБО за пояснения на простом и понятном языке!

А то я после множеств прочитанных статей по этой тематике, начал уже запутываться. Ведь там пишут очень много всего и разного, а про то как все это хозяйство будет взаимодействовать с остальными службами и ОС в целом - можно лишь догадываться или получить "неожиданный сюрприз" уже по факту...