CentOS 7でyum install nginxを使ってnginx 1.24.0をインストールし、/etc/nginx/nginx.conf内のuserディレクティブをrootに変更しても、failed (13: Permission denied) in /etc/nginx/nginx.conf:31というエラーが発生する場合があります。

ファイルの所有者やパーミッションが正しく設定されていてもSELinuxまたはAppArmorが有効で厳格なポリシーが適用されていると、nginxが必要なファイルにアクセスできないことがあります。以下に、これらのセキュリティモジュールの確認方法と修正手順を説明します。

SELinuxが原因かどうかの調査

1. SELinuxの状態を確認
   sestatusコマンドを実行します。出力でSELinux status: enabledかつCurrent mode: enforcingなら、SELinuxが強制モードで動作しています。
2. 拒否ログの確認
   sudo ausearch -m avc -ts recent | grep nginxで、最近の拒否ログからnginx関連の行を表示します。deniedメッセージが表示されればSELinuxが原因の可能性が高いです。
3. 一時的にPermissiveモードでテスト
   sudo setenforce 0でPerissiveモードに切り替え、sudo systemctl restart nginxでエラーが解消されるか確認します。解消されればSELinuxが問題です。
4. 永続的な解決
   対象ファイル（例：/etc/nginx/conf.d/myapp.conf）のSELinuxコンテキストを適切なタイプに変更します。
   sudo chcon -t httpd_sys_content_t /etc/nginx/conf.d/myapp.conf
   より安全な方法として、semanage fcontextでラベルを永続的に設定し、restoreconを実行することも推奨します。

AppArmorの確認と対処

UbuntuなどAppArmorを使用する環境では以下の手順で調査します。

1. AppArmorの状態確認
   sudo aa-statusで有効なプロファイル一覧を表示します。
2. 拒否ログの確認
   sudo grep apparmor /var/log/syslog | grep nginxで関連する拒否メッセージを検索します。
3. ポリシーの調整
   /etc/apparmor.d/下にあるnginx用のプロファイル（例：usr.sbin.nginx）を編集し、必要なファイルへのアクセスルールを追加します。編集後はsudo service apparmor reloadでポリシーを再読み込みします。

以上の手順により、SELinuxやAppArmorによるアクセス拒否が原因のPermission deniedエラーを解決できます。