Użytkownik na wirtualnego hosta w Nginx

Czy jest możliwe, aby w Nginx skonfigurować innego użytkownika dla wirtualnego hosta?

Coś jak

 server {
     user myprojectuser myprojectgroup;
     ...
 }

Nie, ponieważ wszystkie sekcje serwera w konfiguracji nginx są obsługiwane z tego samego zestawu procesów roboczych. Ponadto, z punktu widzenia bezpieczeństwa, lepiej uruchomić go w ten sposób, ponieważ oznacza to, że serwer automatycznie nie drażni treści (nieobecne głupoty takie jak a chmod -R 0777), więc jeśli istnieje luka w zabezpieczeniach nginx, żadna treść jest zagrożony.

Tak. Jest to możliwe i zalecane dla dodatkowego bezpieczeństwa (zobacz dlaczego poniżej).

Biorąc pod uwagę, że używasz PHP-FPM (prawdopodobnie, jak to jest najczęściej), możesz utworzyć bufor dla każdej domeny, należący do innego użytkownika.

PS: Tutaj napisałem szczegółowy samouczek krok po kroku:

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

1. Utwórz szpule:

Dodaj szpule /etc/php/7.0/fpm/pool.d/www.conflub utwórz nowy .confplik dla każdej nowej szpuli.

Szpula nr 1 (myuser1):

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

Szpula # 2 (myuser2):

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

PS: Trzymaj listen.owner / listen.group dla tego samego użytkownika nginx (zwykle www-data ).

2. Przypisz każdą bufor do bloku serwera (host wirtualny dla użytkowników Apache):

Host 1:

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

Host 2:

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

Uruchom ponownie usługi FPM i NGINX

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

Testowanie:

Utwórz plik pinfo.php (lub inną nazwę), który pokaże bieżącego użytkownika procesu:

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

Lub utwórz plik pinfo.php przez bash:

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

Następnie otwórz „ http: //.../pinfo.php ” w przeglądarce.

Dlaczego warto korzystać z wielu użytkowników (ze względów bezpieczeństwa):

Jeśli prowadzisz wszystkie witryny pod tym samym użytkownikiem ( www-data ), wywołanie PHP do system () / passthru () / exec () będzie miało dostęp do wszystkich stron! NGINX nie ochroni cię przed tym. PHP jest tylko przykładem, ale każdy popularny język serwera WWW ma podobne wywołania. Jako haker możesz „ ls .. ”, aby poruszać się po wszystkich witrynach, a „ cp / echo / mv ”, aby napisać własny kod w dowolnym pliku (w tym w innych plikach na stronie). Nawet jeśli wszystkie witryny na serwerze są własnością tej samej osoby (np. Ciebie), wskazane jest, aby uruchomić każdą witrynę z innym użytkownikiem, ponieważ uniemożliwi to ewentualnym hakerom / wirusom (np. Wirusom Wordpress) dostęp do innych stron.

W odpowiedzi na powyższy komentarz Iwana, który wydaje się mieć zastosowanie do PO. Dwie rzeczy:

1. Katalog główny aplikacji byłby podobny do /blah/peterWeb/htmli /blah/johnWeb/html. Zarówno NGINX, jak i Apache2 nie pozwoliłyby na przeglądanie lub działanie w drugim katalogu, nawet jeśli oba działają w sieci jako dane grupy.

2. Objęcie każdego drzewa katalogów własnym uprawnieniem pozwoliłoby każdemu użytkownikowi na ssh / login do systemu UNIX i zachowanie ich katalogów w tajemnicy - po prostu nie umieszczaj każdego użytkownika w grupie danych www. Jeśli się zgadzasz, to zdanie:

   każdy użytkownik, który może obsługiwać skrypt PHP lub proces cgi-bin, może uzyskać dostęp do dowolnego pliku dostępnego dla użytkownika www-data.

   może być dokładniej napisany jako:

   każdy użytkownik, którego umieścisz w tej samej grupie co serwer apache / nginx (www-data), może wtedy zrobić, co chce (w tym uruchomić skrypt php) w ​​dowolnym dostępnym dla niego pliku (który zasadniczo byłby wszystkim w Internecie serwer).

EDYCJA 1: Musiałem rozwiązać niektóre problemy z administratorem serwera. Zagłębiłem się w ten temat. Nie wiedziałem, jak dokładne są informacje Ivana! Jeśli chcesz dać użytkownikom możliwość przesyłania i uruchamiania skryptów w konfiguracji hostingu współdzielonego, zwróć uwagę. Oto jedno podejście . Nienawidzę Iwana do upewnienia się, że zrozumiałem tę lukę.