Utilisateur par hôte virtuel dans Nginx

Est-il possible dans nginx de configurer un utilisateur différent par hôte virtuel?

Quelque chose comme

 server {
     user myprojectuser myprojectgroup;
     ...
 }

Non, car toutes les strophes de serveur d'une configuration nginx sont servies à partir du même ensemble de processus de travail. De plus, du point de vue de la sécurité, il vaut mieux l' exécuter comme ça, car cela signifie que le contenu est automatiquement inscriptible par le serveur Web (en l'absence de stupidités comme a chmod -R 0777), de sorte que s'il y a une vulnérabilité dans nginx, aucun du contenu est à risque.

Oui. Il est possible et recommandé pour plus de sécurité (voir pourquoi ci-dessous).

Étant donné que vous utilisez PHP-FPM (vous l'êtes probablement, comme c'est le plus courant), vous pouvez créer un spool, appartenant à un utilisateur différent, pour chaque domaine.

PS: j'ai écrit un tutoriel détaillé étape par étape ici:

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

1. Créez des bobines:

Ajoutez les bobines /etc/php/7.0/fpm/pool.d/www.confou créez un nouveau .conffichier pour chaque nouvelle bobine.

Bobine # 1 (myuser1):

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

Bobine # 2 (myuser2):

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

PS: Gardez votre listen.owner / listen.group au même utilisateur nginx (généralement www-data ).

2. Attribuez chaque spoule à son bloc serveur (hôte virtuel pour les utilisateurs apache):

Hôte 1:

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

Hôte 2:

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

Redémarrez les services FPM et NGINX

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

Essai:

Créez un fichier pinfo.php (ou n'importe quel nom) qui montrera l'utilisateur du processus actuel:

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

Ou créez le fichier pinfo.php via bash:

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

Ouvrez ensuite " http: //.../pinfo.php " sur votre navigateur.

Pourquoi utiliser plusieurs utilisateurs (raisons de sécurité):

Si vous exécutez tous vos sites Web sous le même utilisateur ( www-data ), un appel PHP à system () / passthru () / exec () aura accès à tous les sites Web! NGINX ne vous protégera pas contre cela. Le PHP n'est qu'un exemple, mais tout langage de serveur Web populaire a des appels similaires. En tant que hacker, vous pouvez " ls .. " pour naviguer sur tous les sites Web et " cp / echo / mv " pour écrire votre propre code dans n'importe quel fichier (y compris les fichiers d'un autre site Web). Même si tous les sites Web du serveur appartiennent à la même personne (par exemple, vous), il est conseillé d'exécuter chaque site Web avec un utilisateur différent, car cela empêchera d'éventuels pirates / virus (par exemple, les virus Wordpress) d'accéder à vos autres sites Web.

En réponse au commentaire d'Ivan ci-dessus et qui semble applicable au PO. Deux choses:

1. La racine du document d'application serait quelque chose comme /blah/peterWeb/htmlet /blah/johnWeb/html. NGINX et Apache2 ne permettraient pas à l'un de lire attentivement ou de fonctionner dans l'autre répertoire, même s'ils exécutent tous les deux www-data en groupe.

2. Le fait de placer chaque arborescence de répertoires sous leur propre autorisation utilisateur permettrait à chaque utilisateur de ssh / se connecter à un système UNIX et de garder leurs répertoires privés pour chacun - il suffit de ne pas placer chaque utilisateur dans le groupe www-data. Si vous êtes d'accord, alors votre phrase:

   chaque utilisateur pouvant servir un script PHP ou un processus cgi-bin peut accéder à n'importe quel fichier accessible à l'utilisateur www-data.

   pourrait être écrit avec plus de précision:

   chaque utilisateur que vous mettez dans le même groupe que le serveur apache / nginx (www-data) peut alors faire ce qu'il veut (y compris exécuter un script php) dans n'importe quel fichier qui lui est accessible (qui serait essentiellement tout sur un site web serveur).

EDIT 1: Devant résoudre certains problèmes d'administration du serveur, j'ai approfondi ce sujet. Je ne savais pas à quel point les informations d'Ivan étaient exactes! Si vous avez l'intention de donner aux utilisateurs la possibilité de télécharger et d'exécuter des scripts sur une configuration d'hébergement partagé, alors prenez garde. Voici une approche . Chapeau à Ivan pour m'être assuré d'avoir bien compris cette vulnérabilité.