Pourquoi nginx démarre le processus en tant que root?
J'ai installé le serveur nginx. Je viens de vérifier les ports d'écoute et j'ai vu ce qui suit:
$ Sudo lsof -nP -i | grep LISTEN
sshd 614 root 3u IPv4 7712 0t0 TCP *:22 (LISTEN)
nginx 822 root 7u IPv4 8745 0t0 TCP *:80 (LISTEN)
nginx 827 www-data 7u IPv4 8745 0t0 TCP *:80 (LISTEN)
nginx 828 www-data 7u IPv4 8745 0t0 TCP *:80 (LISTEN)
nginx 829 www-data 7u IPv4 8745 0t0 TCP *:80 (LISTEN)
nginx 830 www-data 7u IPv4 8745 0t0 TCP *:80 (LISTEN)
.
.
.
Et je suis simplement intéressé par la raison pour laquelle il existe quatre processus nginx exécutés en tant qu'utilisateur "www-data" et un en tant qu'utilisateur "root"?
Le processus que vous avez remarqué est le processus maître, le processus qui démarre tous les autres processus nginx. Ce processus est démarré par le script init qui démarre nginx. La raison pour laquelle ce processus s'exécute en tant que root est simplement parce que vous l'avez démarré en tant que root! Vous pouvez le démarrer en tant qu'un autre utilisateur, mais vous devrez vous assurer que toutes les ressources dont nginx a besoin sont disponibles pour cet utilisateur. Ce serait généralement au moins/var/log/nginx et le fichier pid sous/var/run /.
Plus important encore; Seuls les processus root peuvent écouter les ports inférieurs à 1024. Un serveur Web s'exécute généralement sur le port 80 et/ou 443. Cela signifie qu'il doit être démarré en tant que root.
En conclusion, le processus maître exécuté par root est tout à fait normal et dans la plupart des cas nécessaire pour un fonctionnement normal.
Edit: exécuter quoi que ce soit en tant que root comporte un risque de sécurité implicite. Normalement, les développeurs de ce type de logiciel ont beaucoup de connaissances sur les vecteurs d'attaque et prennent grand soin d'exécuter le moins possible en tant que root. En fin de compte, vous devez simplement faire confiance à la bonne qualité du logiciel.
Si vous vous sentez toujours mal à l'aise, il existe un moyen d'exécuter nginx en tant qu'autre utilisateur et d'utiliser toujours des ports inférieurs à 1024. Vous pouvez utiliser iptables pour rediriger tout le trafic entrant sur le port 80 vers un autre port, par exemple 8080, et demander à nginx d'écouter sur ce port.
La plupart des serveurs (Apache, Nginx, etc.) ont un processus parent qui appartient à root, qui utilise ensuite des copies des nœuds de travail à l'aide d'un utilisateur disposant de moins d'informations d'identification. Dans ce cas, c'est www-data.
Exemple
Si vous regardez le fichier de configuration de nginx, /etc/nginx/nginx.conf, vous remarquerez des lignes comme celle-ci:
user nginx;
worker_processes 2; #change to the number of your CPUs/Cores
worker_rlimit_nofile 8192;
La plupart des serveurs ont des options similaires à celle-ci qui stipulent quel utilisateur exécuter les nœuds esclaves et combien d'entre eux.
Sécurité
L'exposition de services qui ont un accès root est souvent mentionnée comme une insécurité potentielle. Cependant, vous devez souvent être root pour vous connecter à des ports allant de 1 à 1024, il n'y a donc vraiment rien que vous puissiez faire si vous voulez qu'un serveur écoute sur les ports 80 ou 443 par exemple.
De plus, si un service est bien écrit et correctement configuré, il n'est pas nécessairement en soi préjudiciable à votre sécurité. Les applications qui s'exécutent au-dessus d'Apache & Nginx sont vraiment les véritables sources d'attaques par débordement de tampon ou par injection de serveur SQL, car les applications sont les services qui exposent les points d'entrée des données malformées à injecter dans votre pile de serveurs.
Apache et Nginx seuls n'acceptent généralement aucune entrée au-delà des méthodes GET/POST qu'ils acceptent.
C'est la façon dont l'application est packagée. Sur la plupart des * nix, la configuration par défaut est qu'un utilisateur non privilégié ne peut pas écouter sur un port <1024 et les serveurs Web utilisent 80 et 443.
Linux 2.2+, Solaris 10+ et FreeBSD permettent tous aux utilisateurs non root d'écouter sur des ports inférieurs à 1024, mais pas par défaut. La plupart ont accepté l'utilisation de root, il reste donc utilisé.
Autre que l'accès pour se lier au port privilégié, vous devez vous assurer que l'utilisateur exécutant nginx a accès à tous les fichiers dont il a besoin. Vous avez probablement vous n'avez pas besoin d'aller aussi loin mais définissez simplement les autorisations correctes sur les fichiers/répertoires. Vous devez également vérifier que les scripts de démarrage ne font rien de sournois comme les changements de ulimit (comme mysql semble toujours le faire).
capacités Linux
setcap et getcap vous permet de modifier ou d'afficher le cap_net_bind_service capacité d'un exécutable. Ce sera en vigueur pour toute personne qui exécute le binaire.
setcap cap_net_bind_service=+ep /usr/sbin/nginx
SELinux offre la possibilité de configurer et de contrôler les capacités au niveau de l'utilisateur.
Paramètres système Freebsd
Les paramètres de port réservés sont globaux pour le système
sysctl net.inet.ip.portrange.reservedhigh=0
sysctl net.inet.ip.portrange.reservedlow=0
Privilèges Solaris
Solaris offre un contrôle fin des privilèges au niveau de l'utilisateur. Ce sont les privilèges pour Apache mais ils sont susceptibles de fonctionner également pour nginx.
/usr/sbin/usermod -K defaultpriv=basic,proc_exec,proc_fork,net_privaddr nginx
Je voudrais ajouter à tous les autres réponses. Bien que nginx soit démarré en tant que root, il ne s'exécute pas réellement en tant que root. L'utilisateur (nginx, www-data, etc.) qu'il exécute réellement est généralement une connexion restreinte/emprisonnée (vous ne pouvez pas vous connecter avec, seuls certains fichiers sont accessibles). C'est l'un des avantages de l'utilisation de Linux pour les serveurs Web par opposition à Windows. Ce processus est appelé fork ( vous pouvez trouver plus de détails dans cet article Wikipedia ) et il utilise également setuid et/ou setgid (- ce qui est également expliqué dans un article Wikipedia ) pour changer l'utilisateur et/ou le groupe. Dans une configuration sécurisée, un pirate ne pourrait pas accéder au processus parent et utiliser le compte root. Ce n'est pas toujours vrai car un pirate pourrait utiliser une sorte d'exploit pour accéder à la racine (il y avait une vulnérabilité dans nginx 1.4.0 et inférieure qui permettait aux pirates d'accéder à la racine).