Користувач на віртуальний хост у Nginx

Чи можливо в nginx налаштувати іншого користувача на віртуального хоста?

Щось на зразок

 server {
     user myprojectuser myprojectgroup;
     ...
 }

Ні, тому що всі серверні строфи в конфігурації nginx подаються з одного набору робочих процесів. Крім того, з точки зору безпеки, вам краще запустити його так, оскільки це означає, що веб-сервер вміст автоматично не підходить (відсутні дурість, як 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: Тримайте вашу liste.owner / liste.group того самого користувача nginx (зазвичай www-data ).

2. Призначте кожну котушку своєму блоку серверів (віртуальному хосту для користувачів апаш):

Ведучий 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 до системи () / passthru () / exec () матиме доступ до всіх веб-сайтів! NGINX не захистить вас від цього. PHP - лише приклад, але будь-яка популярна мова веб-сервера має подібні дзвінки. Як хакер, ви можете " лс .. " переходити по всіх веб-сайтах і " cp / echo / mv " писати власний код у будь-який файл (включаючи інші файли веб-сайту). Навіть якщо всі веб-сайти на сервері належать одній особі (наприклад, ви), доцільно запускати кожен веб-сайт з іншим користувачем, оскільки це не дозволить потенційним хакерам / вірусам (наприклад, вірусам Wordpress) отримати доступ до інших ваших веб-сайтів.

У відповідь на коментар Івана вище та, який здається застосовно до ОП. Дві речі:

1. Корінь документа програми буде чимось схожим /blah/peterWeb/htmlі /blah/johnWeb/html. І NGINX, і Apache2 не дозволять одному переслідувати або працювати в іншому каталозі, навіть якщо вони обидва використовують дані www як дані у групі.

2. Якщо розмістити кожне дерево каталогів під власним дозволом користувача, це дозволить кожному користувачеві ssh / login до системи UNIX та зберігати свої каталоги приватними для кожного - просто не слід розміщувати кожного користувача у групі даних www. Якщо ви згодні, то ваше речення:

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

   може бути більш точно записано як:

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

РЕДАКТИКА 1: Доводиться вирішувати деякі проблеми адміністратора сервера, я детальніше розглядав цю тему. Я не знав, наскільки точні дані Івана! Якщо ви маєте намір надати користувачам можливість завантажувати та запускати сценарії в конфігурації спільного хостингу, тоді зверніть увагу. Ось один підхід . Хед-порада Івану, щоб переконатися, що я зрозумів цю вразливість.