Пользователь на виртуальный хост в Nginx

Возможно ли в nginx настроить разных пользователей для каждого виртуального хоста?

Что-то вроде

 server {
     user myprojectuser myprojectgroup;
     ...
 }

security nginx

Да. Это возможно и рекомендуется для дополнительной безопасности (см. Почему ниже).

Учитывая, что вы используете PHP-FPM (скорее всего, так и используете, поскольку это чаще всего), вы можете создать спул, принадлежащий другому пользователю, для каждого домена.

PS: Я написал подробное пошаговое руководство здесь:

https://learnwithdaniel.com/2019/06/user-per-virtual-host-nginx/

1. Создайте катушки:

Добавьте катушки в /etc/php/7.0/fpm/pool.d/www.conf или создайте новый .conf файл для каждой новой катушки.

Катушка №1 (myuser1):

[myprojectuser1]
user = myuser1
group = myprojectgroup
..
listen = /run/php/myuser1.sock
...  
listen.owner = www-data
listen.group = www-data

Катушка №2 (myuser2):

[myprojectuser2]
user = myuser2
group = myprojectgroup
..
listen = /run/php/myuser2.sock
...  
listen.owner = www-data
listen.group = www-data

PS: держите свой listen.owner / listen.group тому же пользователю nginx (обычно www-data).

2. Назначьте каждую очередь на свой серверный блок (виртуальный хост для пользователей apache):

Хост 1:

server {
  ...
  location ~ \.php$ {
    fastcgi_pass unix:/run/php/myuser1.sock;
  }
  ...
}

Хост 2:

server {
  ...
  location ~ \.php$ {
    fastcgi_pass unix:/run/php/myuser2.sock;
  }
  ...
}

Перезапустите службы FPM и NGINX.

sudo /etc/init.d/php7.0-fpm restart
sudo service nginx restart

Тестирование:

Создать pinfo.php (или любое другое имя) файл, который покажет текущего пользователя процесса:

<?php 
echo str_replace("\n", '<br>', shell_exec('ps -u -p '.getmypid()));

Или создайте pinfo.php файл через bash:

echo "<?php echo str_replace(\"\\n\", '<br>', shell_exec('ps -u -p '.getmypid()));" > pinfo.php

Затем откройте "http: //.../pinfo.php"в вашем браузере.

Зачем использовать несколько пользователей (из соображений безопасности):

Если вы запускаете все свои сайты под одним и тем же пользователем (www-data), PHP-вызов system () / passthru () / exec () будет иметь доступ ко всем веб-сайтам! NGINX не защитит вас от этого. PHP - это просто пример, но любой популярный язык веб-серверов имеет похожие вызовы. Как хакер, вы можете "ls .."перемещаться по всем веб-сайтам и"cp / echo / mv"для написания собственного кода в любом файле (включая файлы других веб-сайтов). Даже если все веб-сайты на сервере принадлежат одному и тому же человеку (например, вам), рекомендуется запускать каждый веб-сайт с другим пользователем, поскольку это предотвратит возможное хакеры / вирусы (например, вирусы Wordpress) от доступа к другим вашим веб-сайтам.

Нет, потому что все серверные разделы в конфигурации nginx обслуживаются одним и тем же набором рабочих процессов. Кроме того, с точки зрения безопасности вы лучше чтобы запустить его таким образом, поскольку это означает, что контент автоматически не может быть записан веб-сервером (отсутствие глупостей, таких как chmod -R 0777), так что если в nginx есть уязвимость, ни один контент не подвергается риску.

В ответ на комментарий Ивана выше, который кажется применимым к OP. Две вещи:

Корень документа приложения будет примерно таким: /blah/peterWeb/html и /blah/johnWeb/html. И NGINX, и Apache2 не позволят одному просматривать или работать в другом каталоге, даже если они оба используют www-data как группу.
Помещение каждого дерева каталогов под их собственное разрешение пользователя позволит каждому пользователю ssh / войти в систему UNIX и сохранить свои каталоги частными для каждого - просто не помещайте каждого пользователя в группу www-data. Если согласны, то ваше предложение:

каждый пользователь, который может обслуживать сценарий PHP или процесс cgi-bin, может получить доступ к любому файлу, доступному пользователю www-data.

можно было бы более точно записать как:

каждый пользователь, которого вы помещаете в ту же группу, что и сервер apache / nginx (www-data), может затем делать все, что они хотят (включая запуск php-скрипта) в любом доступном ему файле (который, по сути, был бы всем в сети сервер).

РЕДАКТИРОВАТЬ 1: Чтобы решить некоторые проблемы с администратором сервера, я углубился в эту тему. Я не знал, насколько точной была информация Ивана! Если вы собираетесь предоставить пользователям возможность загружать и запускать сценарии в конфигурации общего хостинга, обратите внимание. Вот это один подход. Совет Ивану, чтобы убедиться, что я понял эту уязвимость.