Usuario por host virtual en Nginx

¿Es posible en nginx configurar diferentes usuarios por host virtual?

Algo como

 server {
     user myprojectuser myprojectgroup;
     ...
 }

No, porque todas las secciones del servidor en una configuración nginx se sirven desde el mismo conjunto de procesos de trabajo. Además, desde una perspectiva de seguridad, es mejor ejecutarlo así, ya que significa que el servidor web no puede escribir el contenido automáticamente (sin estupideces como a chmod -R 0777), de modo que si hay una vulnerabilidad en nginx, ninguno de los contenidos Está en riesgo.

Sí. Es posible y recomendado para mayor seguridad (ver por qué a continuación).

Teniendo en cuenta que está utilizando PHP-FPM (probablemente lo sea, ya que es lo más habitual), puede crear un spool, propiedad de un usuario diferente, para cada dominio.

PD: escribí un tutorial detallado paso a paso aquí:

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

1. Crear bobinas:

Agregue los spools /etc/php/7.0/fpm/pool.d/www.confo cree un nuevo .confarchivo para cada nuevo spool.

Carrete # 1 (myuser1):

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

Carrete # 2 (myuser2):

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

PD: Mantenga su listen.owner / listen.group con el mismo usuario nginx (generalmente www-data ).

2. Asigne cada spool a su bloque de servidor (host virtual para usuarios de apache):

Anfitrión 1:

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

Anfitrión 2:

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

Reinicie los servicios FPM y NGINX

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

Pruebas:

Cree un archivo pinfo.php (o cualquier nombre) que muestre al usuario actual del proceso:

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

O cree el archivo pinfo.php a través de bash:

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

Luego abra " http: //.../pinfo.php " en su navegador.

Por qué usar múltiples usuarios (razones de seguridad):

Si ejecuta todos sus sitios web bajo el mismo usuario ( www-data ), ¡una llamada PHP al sistema () / passthru () / exec () tendrá acceso a todos los sitios web! NGINX no lo protegerá contra esto. El PHP es solo un ejemplo, pero cualquier lenguaje de servidor web popular tiene llamadas similares. Como hacker, puede " ls .. " para navegar por todos los sitios web y " cp / echo / mv " para escribir su propio código en cualquier archivo (incluidos los archivos de otro sitio web). Incluso si todos los sitios web en el servidor son propiedad de la misma persona (por ejemplo, usted), es recomendable ejecutar cada sitio web con un usuario diferente, ya que evitará que los piratas informáticos / virus (por ejemplo, los virus de Wordpress) accedan a sus otros sitios web.

En respuesta al comentario de Ivan anterior y que parece aplicable al OP. Dos cosas:

1. La raíz del documento de la aplicación sería algo así como /blah/peterWeb/htmly /blah/johnWeb/html. Tanto NGINX como Apache2 no permitirían que uno lea detenidamente u opere en el otro directorio, incluso si ambos ejecutan www-data como grupo.

2. Colocar cada árbol de directorios bajo su propio permiso de usuario permitiría a cada usuario ingresar / iniciar sesión en un sistema UNIX y mantener sus directorios privados para cada uno, simplemente no coloque a cada usuario en el grupo www-data. Si está de acuerdo, entonces su oración:

   cada usuario que puede servir un script PHP o un proceso cgi-bin puede acceder a cualquier archivo accesible para el usuario de www-data.

   podría escribirse con mayor precisión como:

   cada usuario que coloque en el mismo grupo que el servidor apache / nginx (www-data) puede hacer lo que quiera (incluida la ejecución de un script php) en cualquier archivo que sea accesible (que esencialmente sería todo en una web servidor).

EDITAR 1: Al tener que abordar algunos problemas de administración del servidor, estudié más a fondo este tema. ¡No sabía cuán precisa era la información de Ivan! Si tiene la intención de dar a los usuarios la capacidad de cargar y ejecutar scripts en una configuración de alojamiento compartido, preste atención. Aquí hay un enfoque . Felicitaciones a Ivan por asegurarse de entender esta vulnerabilidad.