FastCGI / PHP-FPMを実行するときに(ユーザー「nobody」として)PHPセッションフォルダーに設定するアクセス許可/所有権は何ですか?


17

PHP-FPMがセッションフォルダーに書き込むことができないため、多くのスクリプトを実行するのに問題があります。

"2009/10/01 23:54:07 [エラー] 17830#0:* 24 FastCGIがstderrに送信:" PHP警告:
    不明:open(/ var / lib / php / session / sess_cskfq4godj4ka2a637i5lq41o5、O_RDWR)
    失敗:行0の不明で許可が拒否されました(13)
PHP警告:不明:セッションデータ(ファイル)の書き込みに失敗しました。確認してください
    session.save_pathの現在の設定が正しいこと
    (/ var / lib / php / session)アップストリームの読み取り中に0行目の不明で

これは明らかに許可の問題です。セッションフォルダーの所有者/グループは、WebサーバーのユーザーNGINXです。PHP-FPMはnobodyあたかも実行されるため、nginxグループに追加するのはそれほど簡単ではありません。

一時的な解決策は、のパーミッション設定することです/var/lib/php/sessionへの777-でも、私は、「ベストプラクティス」ではありません感じています。

フォルダーへのデーモン書き込みアクセスを割り当てる必要があるが、次のように実行されている場合のベストプラクティスは何nobodyですか?

回答:


24

私たちの正しい権限

chown -R nobody:nogroup /var/lib/php/session

php-cgi実行するようnobodynginxのは、ユーザーとして実行されていても、nginx


私の場合、所有権/許可の問題ではありませんでした。「3;」を削除します ; "は/ var / libに/ PHP /セッション3" session.save_pathはから=
ジョン・ドウ

1
次のエラーが表示されます:無効なグループ<< nobody:nogroup >> :(
Pathros

私はnobodyこのコード行でPHPを実行している私のユーザーがどれであるかを見ることができました:( <?php echo exec('whoami'); ?>私の場合はwww-data)そしてそれが書いたように簡単chown -R www-data:www-data /var/lib/php/sessionsでした何時間もの検索の後、私に!ありがとう!
ディミター

9

nginxを使用している場合、システムアップデートの実行時にこれに遭遇する可能性があります。

システムを更新すると、グループが/var/lib/php/sessionApacheに変更される場合があります。

sudo chgrp nginx /var/lib/php/*777にアクセス許可を設定する代わりに実行してみてください。これは悪い習慣です。

少なくとも私にはうまくいきました。


1
これは承認済みの回答としてマークする必要があります。
ユダプラビラ

3

/etc/php.ini session.save_pathディレクティブを使用します。

一時的な解決策は、/ var / lib / php / sessionのアクセス許可を777に設定することです-しかし、「ベストプラクティス」ではないと感じています。

「このセットを誰でも読み取り可能なディレクトリに置いた場合、サーバー上の他のユーザーは、そのディレクトリ内のファイルのリストを取得することでセッションをハイジャックできる可能性があります。」


申し訳ありませんが、はっきりしていないと思います:session.save_pathはすでに/ var / lib / php / sessionに設定されています。問題は、PHP-FPMによる書き込みと安全性の両方を実現するために、セッションパスディレクトリに割り当てるアクセス許可と所有権がわからないことです。所有者/グループ「nginxの」(私が実行しているWebサーバ)およびアクセス権などのディレクトリセットを持つ755は、トリックを行うには思えない
教授フリンク

4
1.同じユーザー:nginxのとPHP-FPMのグループ(のいずれかを経由nginx.confまたはphp-fpm.conf)、あなたが700 2.このディレクトリを保つことができるので、chown -R nginx:nobody /var/lib/php/session && chmod -R 770 /var/lib/php/session私はnginxのとPHP-FPMの両方がそれを使用することができると思うので
SaveTheRbtz

2
nginx:nobody(または状況によってはnginx:nogroup)が機能することを確認できます。可能であれば、SaveTheRbtzのオプション1に頼ります。
マイケルジョンソン

3

各php-fpmプールの/ var / lib / php / sessionに0700の権利を持つフォルダーを作成する必要がありました。

このフォルダーの所有者は、php-fpmプールのユーザーおよびグループです。

そして/ var / lib / php / sessionが0777になりました。

この方法が最も安全だと思います。このセッションはphp-fpmプールユーザーのみに表示されます。


1

私は同じ問題を抱えていて、それを解決しました。/tmp(ses_ *ファイルがある場所)に行き、それらをすべて削除しました。その後、すべてがOKでした。

システムが古いロックされたファイルに書き込みを行おうとしていたことがわかる限りです。

私が遊んでいた後に問題が発生しましたphp.ini。私は私の人生から数年を失いましたが、最終的に解決策を見つけました。


1

正しい方法は、セッションフォルダーの所有権をnginxに変更することです。ただし、デフォルトでは、PHP-FPMはnginxユーザーを使用して実行されません。デフォルトでapacheを使用します。

そうは言っても、を編集してPHP-FPMが使用するユーザーを変更する必要があります/etc/php-fpm.d/www.conf

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
; RPM: apache Choosed to be able to access some dir as httpd
user = nginx
; RPM: Keep a group allowed to write in log dir.
group = nginx

PHP-FPMを再起動すると、準備完了です。

service php-fpm restart


PHPセッションパスの場所は、に見出すことができる/etc/php.inisession.save_path/var/lib/php/sessionデフォルトです。

phpセッションフォルダーの所有権とグループを更新するコマンド

chown -R nginx:nginx /var/lib/php/session

そして、あなたはのchmodを使っても良いはずです700


1

ディレクトリ/ var / lib / php / sessionsにはスティッキービット権限が必要です。

sudo chmod 1773 /var/lib/php/sessions

ls -al /var/lib/php/
drwxr-xr-x  4 root root   .
drwxr-xr-x 51 root root   ..
drwxr-xr-x  3 root root   modules
drwx-wx-wt  2 root root   sessions

0

@Judderの回答に基づいて、それを機能させるには、nobodynogroupに読み取りおよび書き込み権限を与えるために次のコマンドを追加する必要がありましたchmodは指定されたフォルダの権限を変更します -Rは作成されたフォルダとファイルに同じ権限を適用しますユーザー gの指定されたフォルダーu内、 グループ rの読み取り許可 w書き込み許可

chown -R nobody:nogroup /var/lib/php/session

sudo chmod -R ug+rw /var/lib/php/sessions






弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.