nginxサーバーをインストールしました。ちょうど受信ポートを確認し、以下を確認しました。
$ 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)
.
.
.
「www-data」ユーザーとして4つのnginxプロセスが実行され、「rootユーザー」として1つが実行される理由が気になります。
答え1
目立つプロセスは、他のすべてのnginxプロセスを開始する基本プロセスです。このプロセスは、nginxを起動するinitスクリプトによって開始されます。プロセスがrootとして実行されるのは、単にrootとして起動したからです。他のユーザーとして起動できますが、そのユーザーがnginxに必要なすべてのリソースにアクセスできることを確認する必要があります。通常、少なくとも/var/log/nginxと/var/run/の下のpidファイルです。
最も重要なのは、ルートプロセスだけが1024未満のポートを受信できることです。 Webサーバーは通常、ポート80および/または443で実行されます。これは root で開始する必要があることを意味します。
要約すると、ルートが実行するマスタープロセスは完全に正常であり、ほとんどの場合通常の動作に必要です。
編集：何でもrootとして実行すると、暗黙のセキュリティリスクが発生します。通常、これらのソフトウェア開発者は攻撃ベクトルについて多くのことを知っており、ルートの実行をできるだけ少なくするように細心の注意を払っています。結局、ソフトウェアの品質が良いことを信頼できます。
それでも不安なら、他のユーザーとしてnginxを実行し、1024未満のポートを使い続ける方法があります。 iptables を使用して、ポート 80 からのすべての着信トラフィックを 8080 などの他のポートにリダイレクトし、nginx がそのポートでリッスンできるようにします。
答え2
ほとんどのサーバー（Apache、Nginxなど）には、ルート所有の親プロセスがあり、資格情報が少ないユーザーを使用してワーカーノードのコピーをフォークします。この場合ですwww-data。
はい
nginx設定ファイルを見ると、次/etc/nginx/nginx.confの行が表示されます。
user nginx;
worker_processes 2; #change to the number of your CPUs/Cores
worker_rlimit_nofile 8192;
ほとんどのサーバーには、スレーブノードを実行するユーザーとスレーブノードの数を指定する同様のオプションがあります。
安全
ルートアクセスでサービスを公開することは、潜在的なセキュリティ問題と見なされることがよくあります。ただし、通常、1〜1024の範囲のポートにバインドするにはルートである必要があるため、サーバーがポート80または443でリッスンするようにするには、実際にできることはあまりありません。
また、サービスがうまく作成され、正しく構成されているとしても、必ずしもセキュリティ状態自体に悪影響を及ぼすわけではありません。 ApacheとNginxの上で実行されるアプリケーションは、実際にはバッファオーバーフローまたはSQLサーバーインジェクション攻撃の実際のソースです。これは、サーバースタックに注入されるべき誤った形式のデータのエントリポイントを公開するサービスであるためです。
ApacheとNginx自体は通常、許可されているGET / POSTメソッド以外の入力を許可しません。
答え3
これがアプリケーションがパッケージ化される方法です。ほとんどの* nixでは、デフォルトは許可されていないユーザーがポート< 1024でリッスンできず、Webサーバーが80および443を使用することです。
Linux 2.2+、Solaris 10+、およびFreeBSDでは、すべてroot以外のユーザーが1024未満のポートでリッスンできるようにしますが、デフォルトではそうではありません。ほとんどの人がその使用を承認したrootため、まだ使用されています。
アクセス権を持つポートにバインドされるだけでなく、nginxを実行しているユーザーが必要なすべてのファイルにアクセスできることを確認する必要があります。あなたはできるここまで行く必要はないただし、ファイル/ディレクトリに正しい権限を設定するだけです。また、起動スクリプトが卑劣な変更を行わないことを確認したいと思いますulimit（たとえば、mysqlはいつもそうするようです）。
Linuxの機能
setcapそしてgetcapcap_net_bind_service実行可能ファイルを変更または表示する機能です。これはバイナリを実行しているすべての人に適用されます。
setcap cap_net_bind_service=+ep /usr/sbin/nginx
SELinuxは、ユーザーレベルで機能を設定および制御する機能を提供します。
Freebsdシステム設定
スケジュールされたポート設定はシステム全体に適用されます。
sysctl net.inet.ip.portrange.reservedhigh=0
sysctl net.inet.ip.portrange.reservedlow=0
ソラリス権限
Solarisは、ユーザーレベルで細かい権限制御を提供します。これはApacheに対する権限ですが、nginxにも適用できます。
/usr/sbin/usermod -K defaultpriv=basic,proc_exec,proc_fork,net_privaddr nginx
答え4
他の人の回答に追加したいです。 nginxはrootで始まりますが、実際にはrootとして実行されません。実際に実行されるユーザー（nginx、www-dataなど）は通常制限されているか、刑務所に閉じ込められたログインです（このアカウントではログインできず、特定のファイルにのみアクセスできます）。これは、Windowsと比較してLinuxをWebサーバーとして使用する利点の1つです。このプロセスをfork（このウィキペディアの記事で詳細を見ることができます。）およびまたsetuidおよび/またはsetgid（これはウィキペディアの記事でも説明されています。）ユーザーおよび/またはグループを変更します。セキュリティ設定では、ハッカーは親プロセスにアクセスしたり、rootアカウントを悪用したりすることはできません。しかし、これが必ずしも真実ではない。ハッカーがルートアクセス権を取得するために悪用する可能性がある脆弱性があるためです（nginx 1.4.0以前では、ハッカーがルートアクセス権を取得する可能性がある脆弱性があります）。