なぜnginxはrootとしてプロセスを開始するのですか？

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つのnginxプロセスがある理由に興味がありますか？

気付いたプロセスはマスタープロセスであり、他のすべてのnginxプロセスを開始するプロセスです。このプロセスは、nginxを起動するinitスクリプトによって開始されます。このプロセスがルートとして実行されている理由は、単にルートとして起動したためです！別のユーザーとして起動できますが、nginxが必要とするすべてのリソースがこのユーザーに利用可能であることを確認する必要があります。通常、少なくとも/ var / log / nginxと/ var / run /の下のpid-fileになります。

最も重要なこと; ルートプロセスのみが1024未満のポートをリッスンできます。通常、Webサーバーはポート80または443で実行されます。つまり、ルートとして起動する必要があります。

結論として、ルートで実行されているマスタープロセスは完全に正常であり、ほとんどの場合、通常の操作に必要です。

編集：ルートとして何かを実行すると、暗黙的なセキュリティリスクが生じます。通常、この種のソフトウェアの開発者は、攻撃ベクトルに関する多くの知識を持ち、rootとして可能な限り実行しないよう細心の注意を払っています。最終的には、ソフトウェアが良質であることを単に信頼する必要があります。

それでも不安がある場合は、nginxを別のユーザーとして実行し、1024未満のポートを使用する方法があります。iptablesを使用して、ポート80のすべての着信トラフィックを別のポート（8080など）にリダイレクトし、nginxにそのポートでリッスンさせることができます。

ほとんどのサーバー（Apache、Nginxなど）には、rootが所有する親プロセスがあります。このプロセスは、資格の低いユーザーを使用してワーカーノードのコピーをフォークします。この場合、それは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の範囲のポートにバインドするにはrootになる必要があるため、サーバーがポート80または443などをリッスンするようにする場合にできることは何もありません。

また、サービスが適切に記述され、適切に構成されている場合、それ自体が必ずしもセキュリティ体制に有害ではありません。アプリケーションはサーバースタックに挿入される不正なデータのエントリポイントを公開しているサービスであるため、ApacheおよびNginxで実行されるアプリケーションは、実際にバッファーオーバーフローまたはSQLサーバーインジェクション攻撃の真のソースです。

ApacheとNginx自体は、一般に、受け入れているGET / POSTメソッド以外の入力を受け入れません。

これがアプリケーションのパッケージ方法です。ほとんどの* nixでは、デフォルトのセットアップは、特権のないユーザーは1024未満のポートでリッスンできず、Webサーバーは80と443を使用します。

Linux 2.2以降、Solaris 10以降、およびFreeBSDはすべて、root以外のユーザーが1024未満のポートでリッスンできるようにしますが、デフォルトではありません。ほとんどが使用を受け入れているrootため、使用中のままです。

特権ポートにバインドするアクセス以外に、nginxを実行しているユーザーが必要なすべてのファイルにアクセスできることを確認する必要があります。おそらくこれまでは必要ありませんが、ファイル/ディレクトリに正しい許可を設定するだけです。また、起動スクリプトがulimit変更のような卑劣なことをしないことも確認する必要があります（mysqlが常にそうであるように）。

Linuxの機能

setcapそして、getcap変更または表示できcap_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の特権

Solarisは、ユーザーレベルで特権をきめ細かく制御します。これらはapacheの特権ですが、nginxでも同様に機能する可能性があります。

/usr/sbin/usermod -K defaultpriv=basic,proc_exec,proc_fork,net_privaddr nginx

みんなに答えを加えたいです。nginxはルートとして起動されますが、実際にはルートとして実行されていません。通常、制限付き/ジェイルログインとして実際に実行しているユーザー（nginx、www-dataなど）（ログインできません。特定のファイルにのみアクセスできます）。これは、WindowsではなくWebサーバーにLinuxを使用する長所の1つです。このプロセスが呼び出されるfork（あなたはこのWikipediaの記事で詳細を見つけることができます）、それはまた、使用setuidおよび/またはsetgid（また、Wikipediaの記事で説明されています）ユーザーやグループを変更します。安全なセットアップでは、ハッカーは親プロセスにアクセスしてルートアカウントを利用することはできません。ハッカーが何らかの悪用を利用してルートアクセスを取得する可能性があるため、これは必ずしも当てはまりません（nginx 1.4.0以前には、ハッカーがルートアクセスを取得できる脆弱性がありました）。