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

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

Что-то типа

 server {
     user myprojectuser myprojectgroup;
     ...
 }

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

В ответ на комментарий Ивана выше и который представляется применимым к ФП. Две вещи:

1. Корень документа приложения будет что-то вроде /blah/peterWeb/htmlи /blah/johnWeb/html. И NGINX, и Apache2 не позволят одному просматривать или работать в другом каталоге, даже если они оба используют www-данные как группу.

2. Размещение каждого дерева каталогов под собственным разрешением пользователя позволит каждому пользователю входить в систему ssh / login в системе UNIX и сохранять свои каталоги закрытыми для каждого - просто не помещайте каждого пользователя в группу www-data. Если вы согласны, то ваше предложение:

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

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

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

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