User per virtual host in Nginx

Question

Is it possible in nginx configure different user per virtual host?

Something like

 server {
     user myprojectuser myprojectgroup;
     ...
 }

Answer 1

No, because all server stanzas in an nginx config are served from the same set of worker processes. Furthermore, from a security perspective, you're better to run it like that, as it means that the content is automatically unwritable by the webserver (absent stupidities like a chmod -R 0777), so that if there is a vulnerability in nginx, none of the content is at risk.

Answer 2

Yes. It is possible and recommended for extra security (see why below).

Considering that you are using PHP-FPM (you probably are, as it is the most usual), you can create a spool, owned by a different user, for each domain.

PS: I wrote a detailed step-by-step tutorial here:

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

1. Create spools:

Add the spools to /etc/php/7.0/fpm/pool.d/www.conf or create a new .conf file for each new spool.

Spool #1 (myuser1):

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

Spool #2 (myuser2):

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

PS: Keep your listen.owner/listen.group to the same nginx user (usually www-data).

2. Assign each spool to its server block (virtual host for apache users):

Host 1:

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

Host 2:

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

Restart FPM and NGINX services

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

Testing:

Create a pinfo.php (or whatever name) file that will show the current process user:

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

Or create the pinfo.php file via bash:

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

Then open "http://.../pinfo.php" on your browser.

---

Why to use multiple users (security reasons):

If you run all your websites under the same user (www-data), a PHP call to system()/passthru()/exec() will have access to all websites! NGINX will not protect you against this. The PHP is just an example, but any popular webserver language have similar calls. As a hacker, you can "ls .." to navigate through all websites and "cp/echo/mv" to write your own code in any file (including another website files). Even if all websites on the server are owned by the same person (ex. you) it's advisable to run each website with a different user, as it will prevent eventual hackers/virus (ex. Wordpress viruses) from accessing your other websites.

Answer 3

In response to Ivan's comment above and which seems applicable to the OP. Two things:

1. The application document root would be something like /blah/peterWeb/html and /blah/johnWeb/html. Both NGINX and Apache2 would not allow one to peruse or operate in the other directory even if they are both running www-data as group.

2. Placing each directory tree under their own user permission would allow each user to ssh/login to a UNIX system and keep their directories private to each - just don't put each user into the www-data group. If you agree, then your sentence:

   every user that can serve a PHP script or a cgi-bin process can access any file accessible to the www-data user.

   might be more accurately written as:

   every user that you put in the same group as the apache/nginx server (www-data) can then do whatever they want (including running a php script) in any file that is accessible to it (which would essentially be everything on a web server).

EDIT 1: Having to address some Server Admin issues I looked further into this topic. I was unaware of how accurate Ivan's information was! If you intend to give users the ability to upload and run scripts on a shared hosting configuration then take heed. Here is one approach. Hat tip to Ivan for making sure I understood this vulnerability.