nginxとphp-fpmの接続で何故www-dataを記述する必要があるのか

Question

##はじめに
私はプログラミング初学者であり、現在サーバー関連の知識を学んでいる段階です。
自分で可能な限り調べた上で質問しておりますが、意味不明な質問をしている場合はお許しください、、。

##環境
Docker 20.10.0
nginx 1.18.0
php 7.4.15

##質問内容
dockerを使用している状況で、nginxとphp-fpmを接続する場合、主にnginx側ではnginx.confとdefault.conf、php側ではzzz-www.confで設定を変更すると思いますが、その設定に関していくつか質問がございます。

1.nginx.confでは実行ユーザーをwww-dataに変更したり、zzz-www.confではlisten.owner = www-data、listen.group = www-dataと設定することがあると思います。
このwww-dataに関して、私の考えが正しいか、また何故www-dataを記述する必要があるのか分からない点がございますので、ご意見を頂きたく存じます。

2.zzz-www.conf内のlisten.mode = 0666の役割について、私の理解が正しいかご意見を頂きたく存じます。

よろしくお願い致します。

##nginx側で実行ユーザーをwww-dataに変更することに対する私の考え

私の理解としましては、/var/run/php-fpm/php-fpm.sockのパーミッションはphp-fpmのデフォルト設定で下記のようになっており、

$ ls -l /var/run/php-fpm/php-fpm.sock

srw------ 1 www-data www-data 0  3月 12 11:01 /var/run/php-fpm/php-fpm.sock

nginx側のデフォルトの実行ユーザーに対して権限が与えられておらず、nginxの実行ユーザーをデフォルトのまま(www-dataではない実行ユーザー)でphp-fpmとの接続を試みると502エラーとなる。

この502エラーを避ける為に、nginxの実行ユーザーをデフォルトからwww-dataに変更してphp-fpm側のwww-dataと統一することで、nginx側にphp-fpmのデフォルトで設定されているパーミッションと同一の権限が与えられ502エラーが起きない。

従って、docker内でnginx.confを用意し、user www-data;を追記することで、nginx側の実行ユーザーをwww-dataにする必要があると考えております。

##zzz-www.confでlisten.owner = www-dataとlisten.group = www-dataを設定する理由は何故か
申し訳ございませんが、この点に関してどのような場合に、下記のようにwww-dataを記述する必要があるのかが分かりません。

#略
listen.owner = www-data
listen.group = www-data
listen.mode = 0666

分からないなりに考えたのですが、nginx.confで、実行ユーザーをuser www-data;(php-fpmのデフォルトユーザー名と同じ名前に変更)と指定して、その実行ユーザー(www-data = owner)や同一のサーバーを利用するグループ全体に対してアクセス権限を設定したい場合に、listen.owner = www-dataとlisten.group = www-dataを書き、アクセス権限をlisten.mode = 0660のように指定する。このような理解で正しいでしょうか？

##zzz-www.conf内のlisten.mode = 0666の役割について
/var/run/php-fpm/php-fpm.sockのパーミッションはphp-fpmのデフォルト設定で下記のようになっており、

$ ls -l /var/run/php-fpm/php-fpm.sock

srw------ 1 www-data www-data 0  3月 12 11:01 /var/run/php-fpm/php-fpm.sock

デフォルトではnginx側の実行ユーザー(www-dataに変更済 = owner)にしか権限を与えていない為、listen.mode = 0666でパーミッションを666することで、nginx側の実行ユーザー(owner)や同一のサーバーを利用するグループ全体(group)に対しても、読み書きの権限を与えている役割を果たしている、という理解で正しいでしょうか？

何卒ご意見くださいますようお願い致します。

Answer 1

この回答は自分の手元で動かしてみたわけではないので、考える補助程度と捉えて頂きたいと思います。

https://www.php.net/manual/ja/install.fpm.configuration.php
このドキュメントによれば、

unix ソケットを使う場合に、そのパーミッションを設定します。Linux では、 読み書きアクセス権限を設定しないとウェブサーバーからの接続を受け付けることができません。

nginxプロセスがどのようにsockファイルを触るか想像してみます。上記記述によれば、sockファイルを使う為には読み書きのアクセス権限が必要なようです。
ということは、nginxプロセスはsockファイルに「通常のファイルを触るのと同じように」読み書きしているのではと推測されます。
ということは、shell scriptを実行する時のユーザーの権限で通常のファイルを触れる必要があるのと同様かなと思います。
つまり、nginxプロセスで動いているユーザー権限でsockファイルが触れる必要があるので、ownerに対して読み書き（6）を与える必要があるのではないかという理解です。
この理解が合っているのであれば、ownerがあっているなら、sockに対して0666権限は必要なく、0600権限で十分なのかもしれません。

Comments

[yuina711]

ご回答ありがとうございます。

>sockファイルを使う為には読み書きのアクセス権限が必要なようです。
ということは、nginxプロセスはsockファイルに「通常のファイルを触るのと同じように」読み書きしているのではと推測されます。

この推測に従い再度考えてみると、nginx側の実行ユーザー(www-data)に読み書きのアクセス権限を与える為に、listen.ownerでnginxの実行ユーザーであるwww-dataを指定、そして、listen.modeで0600を指定することでnginx側の実行ユーザー(www-data = owner)に読み書きのアクセス権限を与える。こういうロジックで相違ないでしょうか。

上記のロジックで考えると、例えば、掲示板のような同じサーバーを利用するユーザ全体、つまりグループ全体にも読み書きのアクセス権限を与えたい場合、listen.group = www-dataを指定して、listen.mode = 0660とすることでグループ全体にも読み書きのアクセス権限を与える。
このようにすることも可能であるということでしょうか？

[yamotuki]

> nginx側の実行ユーザー(www-data)に読み書きのアクセス権限を与える為に、listen.ownerでnginxの実行ユーザーであるwww-dataを指定、そして、listen.modeで0600を指定することでnginx側の実行ユーザー(www-data = owner)に読み書きのアクセス権限を与える。こういうロジックで相違ないでしょうか。

現時点ではそう考えております。

> 例えば、掲示板のような同じサーバーを利用するユーザ全体、つまりグループ全体にも読み書きのアクセス権限を与えたい場合、listen.group = www-dataを指定して、listen.mode = 0660とすることでグループ全体にも読み書きのアクセス権限を与える。

ユーザーというのはLinuxでnginxプロセスを実行しているユーザーという認識です。nginx実行ユーザーのグループだけがwww-dataであるなら、0660権限が必要かと思います。

[yuina711]

ご返信頂きありがとうございます。

>現時点ではそう考えております。

私もこのロジックだと納得することができました。
為になる知見を貸してくださり誠にありがとうございます。

>ユーザーというのはLinuxでnginxプロセスを実行しているユーザーという認識です。

私もそのユーザーを指して質問させていただきました。説明を省いてしまい申し訳ございませんでした。

>nginx実行ユーザーのグループだけがwww-dataであるなら

何度も質問してしまい申し訳ございません。ここが分かり次第、直ぐにベストアンサーとさせていただきたいので、お答え頂けると幸いです。

www-dataがnginx実行ユーザー以外のグループも指している場合(このようなパターンが存在するのか私には分かりませんが)は、listen.group = www-dataを指定して 0660権限を与えることはできない、ということでしょうか？

[yamotuki]

もしかしたら文章解釈の食い違いがあり、的外れな回答になってしまっているかもしれませんが、

> www-dataがnginx実行ユーザー以外のグループも指している場合(このようなパターンが存在するのか私には分かりませんが)は、listen.group = www-dataを指定して 0660権限を与えることはできない、ということでしょうか？

nginx以外のプロセスもwww-dataをグループとして使っている、という解釈をするならば、
「0660権限を与えることはできない」ではなくて不要な権限を渡してしまっているので「0660権限を与えることはセキュリティ上の懸念がある」と考えます。

> www-dataがnginx実行ユーザー以外のグループも指している場合

（nginx実行ユーザがwww-dataではないと仮定した上で）nginx実行ユーザのグループがwww-data以外を指している場合、と読み替えて回答いたしますと、
0660権限を渡しても、userの0"6"60の方でもマッチしませんし、group の06"6"0の方でもマッチしないので、権限不足になります（おそらくpermission denyのようなエラーを吐いた上で502レスポンス?）。

[yuina711]

再度ご返信をいただきまして誠にありがとうございます。

>nginx以外のプロセスもwww-dataをグループとして使っている、という解釈をするならば、
「0660権限を与えることはできない」ではなくて不要な権限を渡してしまっているので「0660権限を与えることはセキュリティ上の懸念がある」と考えます。

仰るとおり、私が仮定した状態でのアクセス権限の付与は、不要なアクセス権限を与えてしまう為セキュリティ上良くないですね、、、。

>（nginx実行ユーザがwww-dataではないと仮定した上で）nginx実行ユーザのグループがwww-data以外を指している場合、と読み替えて回答いたしますと、
0660権限を渡しても、userの0"6"60の方でもマッチしませんし、group の06"6"0の方でもマッチしないので、権限不足になります（おそらくpermission denyのようなエラーを吐いた上で502レスポンス?）。

ご指摘を受け思い出しましたが、以前、listen.ownerでnginxの実行ユーザーとして設定されてないユーザーを指定してしまい、502 Bad Gatewayのようなエラーが発生したことがありました。

この度は、ご教授いただきありがとうございました。
yamotuki様とのやり取りで学んだことは、今後開発する上で活かしたいと思います。
重ねて御礼申し上げます。