Utente per host virtuale in Nginx

In nginx è possibile configurare utenti diversi per host virtuale?

Qualcosa di simile a

 server {
     user myprojectuser myprojectgroup;
     ...
 }

No, perché tutte le stanze del server in una configurazione nginx sono servite dallo stesso insieme di processi di lavoro. Inoltre, dal punto di vista della sicurezza, è meglio eseguirlo in questo modo, poiché significa che il contenuto è automaticamente non scrivibile dal server web (assenze stupide come a chmod -R 0777), in modo che se esiste una vulnerabilità in nginx, nessuno dei contenuti è a rischio.

Sì. È possibile e consigliato per maggiore sicurezza (vedere perché di seguito).

Considerando che stai usando PHP-FPM (probabilmente lo sei, come è il più comune), puoi creare uno spool, di proprietà di un utente diverso, per ogni dominio.

PS: ho scritto un tutorial dettagliato dettagliato qui:

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

1. Crea spool:

Aggiungi gli spool /etc/php/7.0/fpm/pool.d/www.confo crea un nuovo .conffile per ogni nuovo 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: mantieni il tuo hear.owner / Listen.group allo stesso utente nginx (di solito www-data ).

2. Assegnare ogni spool al suo blocco server (host virtuale per utenti 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;
  }
  ...
}

Riavvia i servizi FPM e NGINX

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

test:

Crea un file pinfo.php (o qualunque sia il nome) che mostrerà l'utente del processo corrente:

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

Oppure crea il file pinfo.php tramite bash:

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

Quindi apri " http: //.../pinfo.php " sul tuo browser.

Perché usare più utenti (motivi di sicurezza):

Se gestisci tutti i tuoi siti Web con lo stesso utente ( dati www ), una chiamata PHP a system () / passthru () / exec () avrà accesso a tutti i siti Web! NGINX non ti proteggerà da questo. Il PHP è solo un esempio, ma qualsiasi linguaggio web server popolare ha chiamate simili. Come hacker, puoi " ls .. " per navigare in tutti i siti Web e " cp / echo / mv " per scrivere il tuo codice in qualsiasi file (inclusi altri file di siti Web). Anche se tutti i siti Web sul server sono di proprietà della stessa persona (es. Tu), è consigliabile eseguire ogni sito Web con un utente diverso, in quanto impedirà ad eventuali hacker / virus (es. Virus Wordpress) di accedere ad altri tuoi siti Web.

In risposta al commento di Ivan sopra e che sembra applicabile all'OP. Due cose:

1. La radice del documento dell'applicazione sarebbe qualcosa di simile /blah/peterWeb/htmle /blah/johnWeb/html. Sia NGINX che Apache2 non consentirebbero a uno di esaminare o operare nell'altra directory anche se entrambi eseguono www-data come gruppo.

2. Posizionare ciascun albero di directory sotto la propria autorizzazione utente consentirebbe a ciascun utente di accedere a un sistema UNIX e di mantenere le proprie directory private per ciascuno - semplicemente non mettere ciascun utente nel gruppo www-data. Se sei d'accordo, allora la tua frase:

   ogni utente che può servire uno script PHP o un processo cgi-bin può accedere a qualsiasi file accessibile all'utente www-data.

   potrebbe essere scritto più accuratamente come:

   ogni utente che inserisci nello stesso gruppo del server apache / nginx (www-data) può quindi fare quello che vuole (incluso l'esecuzione di uno script php) in qualsiasi file accessibile (che sarebbe essenzialmente tutto su un web server).

EDIT 1: dovendo affrontare alcuni problemi di amministrazione del server ho approfondito questo argomento. Non ero a conoscenza della precisione delle informazioni di Ivan! Se si intende dare agli utenti la possibilità di caricare ed eseguire script su una configurazione di hosting condiviso, fare attenzione. Ecco un approccio . Consiglio ad Ivan di assicurarsi di aver capito questa vulnerabilità.