コンパイルされるPython mod_wsgiモジュールはSElinux強制モードでApacheサーバー上で動作します
私のPython/Djangoアプリを理想的な設定でRedHatサーバー上で動作させようとしています。 python 3.6を使用する仮想環境でモジュールをチェックするときに依存関係の問題があるため、パッケージのmod_wsgiを使用できませんでした（> python 2.xの依存関係チェックのバグがnumpyとpandas）なので、完全に機能するPIPを使用してmod_wsgiをコンパイルする必要がありました。認識されたディレクトリの1つを使用していないため（クリーンインストールとセキュリティ上の理由からカスタムディレクトリがあります）。 SELinuxをpermissionに設定すると、すべてがうまく機能しますが、アプリケーションが強制モードでSELinuxと連携するようにしたいです。 SELinuxファイルコンテキストを調査して適用しようとしましたが、部分的にしか機能していないようです。
仮想環境でmod_wsgiモジュールのファイルコンテキストを設定すると、次のようになります。
Sudo chcon -t httpd_modules_t（特別な場所）/（virtual_env）/ lib/python（version）/ site-packages/mod_wsgi_server/mod_wsgi-py36/cpython-36m-x86_64-linux-gun.so
Selinuxが強制されているときに新しいファイルコンテキストを設定する前に取得したhttpd起動エラーが消えてサービスが適切に開始されるように見えました... httpdの開始後にページにアクセスすると、次のようになります。
エラー500
selinuxが強制モードの場合。 audit.logを確認しましたが、何も表示されません。
誰かがそれについて何か考えを持っていますか？私のmod_wsgiファイルには現在次の設定があります。
-rwxrwxr-x。ルートルートsystem_u：object_r：httpd_exec_t：s0 mod_wsgi-py（version）.cpython version）m-x86_64-linux-gnu.so
誰でもモジュールを読み取って実行でき、httpdが文句なしに起動するため、これは正しいと感じます。 Apache Webサーバーを起動した後にSelinuxを強制に設定した場合、次のApache Webサーバーが再起動するまで、すべてが正常です。これは、mod_wsgi操作のためにすべてが最初にメモリにロードされることを示唆します。
SELinuxのファイルコンテキストの完全なリストのように見えるものをここで調べました：
---（https://linux.die.net/man/8/httpd_selinux
その人々に関するアイデアはありますか？何が足りないのですか？ありがとう！
助けを求めている人に情報を追加するには：
Httpdを実行したり、ページにアクセスしたりすると、Webページからaudit.logファイルに追加のログが記録されません（エラー500が発生します）。 httpリクエストに移動すると（私のsettings.pyは443に転送されます）、Apacheerror_logに次のエントリが表示されます。
[Fri Apr 26 18:10:58.313753 2019] [wsgi:error] [pid 6294] [remote 142.150.251.220:51864] mod_wsgi (pid=6294): Failed to exec Python script file '/var/www/(custom_Django_dir)/(custom_section)/(site)/(app)/wsgi.py'.
[Fri Apr 26 18:10:58.313840 2019] [wsgi:error] [pid 6294] [remote 142.150.251.220:51864] mod_wsgi (pid=6294): Exception occurred processing WSGI script '/var/www/(custom_Django_dir)/(custom_section)/(site)/(app)/wsgi.py'.
[Fri Apr 26 18:10:58.314117 2019] [wsgi:error] [pid 6294] [remote 142.150.251.220:51864] Traceback (most recent call last):
[Fri Apr 26 18:10:58.314191 2019] [wsgi:error] [pid 6294] [remote 142.150.251.220:51864] File "/var/www/(custom_Django_dir)/(custom_section)/(site)/(app)/wsgi.py", line 18, in <module>
[Fri Apr 26 18:10:58.314206 2019] [wsgi:error] [pid 6294] [remote 142.150.251.220:51864] application = get_wsgi_application()
[Fri Apr 26 18:10:58.314231 2019] [wsgi:error] [pid 6294] [remote 142.150.251.220:51864] File "/var/www/(custom_Django_dir)/(custom_section)/virtual_env/lib64/python3.6/site-packages/Django/core/wsgi.py", line 12, in get_wsgi_application
[Fri Apr 26 18:10:58.314250 2019] [wsgi:error] [pid 6294] [remote 142.150.251.220:51864] Django.setup(set_prefix=False)
[Fri Apr 26 18:10:58.314275 2019] [wsgi:error] [pid 6294] [remote 142.150.251.220:51864] File "/var/www/(custom_Django_dir)/(custom_section)/virtual_env/lib64/python3.6/site-packages/Django/__init__.py", line 24, in setup
[Fri Apr 26 18:10:58.314285 2019] [wsgi:error] [pid 6294] [remote 142.150.251.220:51864] apps.populate(settings.INSTALLED_APPS)
[Fri Apr 26 18:10:58.314307 2019] [wsgi:error] [pid 6294] [remote 142.150.251.220:51864] File "/var/www/(custom_Django_dir)/(custom_section)/virtual_env/lib64/python3.6/site-packages/Django/apps/registry.py", line 81, in populate
[Fri Apr 26 18:10:58.314317 2019] [wsgi:error] [pid 6294] [remote 142.150.251.220:51864] raise RuntimeError("populate() isn't reentrant")
[Fri Apr 26 18:10:58.314350 2019] [wsgi:error] [pid 6294] [remote 142.150.251.220:51864] RuntimeError: populate() isn't reentrant
私も同様の状況にあり、chconは真実の半分にすぎないことがわかりました。問題は、chconで行われた変更が永続的ではなく、最終的にSELinuxによって上書きされることです。
私の場合、virtualenvが/ var/wwwの下にあるため、ほとんどのファイルが正しくラベル付けされました。しかし、共有オブジェクトはhttpd_exec_tである必要があり、これでうまくいきます。
$ semanage fcontext -a -t httpd_exec_t '/var/www/wsgi/env/.*\.so(\..*)?'
$ restorecon -r /var/www/wsgi/env
これらの変更は/etc/selinux/targeted/contexts/files/file_contexts.localにあります。
このようなものを思い付くにはかなりの研究が必要です。 WSGIフレームワークプロバイダーを含むほとんどの人々は、SELinuxを単に非アクティブ化することを提案しているようです。
[編集]関連情報 RedHat SELinuxドキュメント
さて、私はこれを理解したようで、他の人に役立つかもしれません（該当する場合は私を修正してください）：
私が信じる鍵は、機能ファイルのコンテキストです：
実行されるApacheスクリプトに似たスクリプトの場合、CGIのバリエーションのように扱いました（phpスクリプトはデフォルトで同様の方法で扱われるようです）ので、Djangoコアインストール場所を次のように設定します：
Sudo chcon system_u:object_r:httpd_sys_script_exec_t:s0 (your folder name)
静的コンテンツとアップロードディレクトリがアプリごとにグループ化されているため、これを再帰的に実行しませんでした。そのため、Django_rootを実行した後、apps_directories（静的コンテンツが含まれている可能性があるためサイトディレクトリではなくアプリ）にコマンドを再帰的に適用しました。ディレクトリ）速度を上げるために、「-R」再帰オプションを使用してこれを実行する場合：
Sudo chcon -R system_u:object_r:httpd_sys_script_exec_t:s0 (your folder name)
各サイトファイルのアップロードディレクトリと読み取り/書き込みファイル（たとえばsqlite3ファイルなど）を確認し、次の設定を適用してください。
Sudo chcon system_u:object_r:httpd_sys_rw_content_t:s0 (upload folder name)
Sudo chcon system_u:object_r:httpd_sys_rw_content_t:s0 (sqlite3 file name)
また、静的ファイルディレクトリ（css、javascript、images、Djangoテンプレートファイル（* .htmlとテンプレートコード）を含む）には、再帰オプションを使用してこの設定を指定する必要があります。
Sudo chcon -R -t httpd_sys_content_t (folder name)
注：これにより、これらのフォルダー/ファイルは最初のunconfined_u：object_r分類のままになりますが、問題ないようです。
仮想環境をインストールしたディレクトリに、次のコンテキストを適用します。
Sudo chcon -R system_u:object_r:httpd_sys_script_exec_t:s0 (virtual environment directory name)
これは、私のmod_wsgiを完全に実行するための重要な部分のようです。以前にerror_logで取得したエラーは、直感的な手がかりを与えません。基本的に、sys_script_execコンテキストを設定することで削除するselinuxの制限により、キーライブラリファイルにアクセスできません。
* .soライブラリをコンパイルした場合（私のmod_wsgiで行ったように）、この手順を最後に* .soファイルのあるディレクトリで行う必要があります（私の場合、コンパイルしたmod_wsgi.soは（Djangoアプリフォルダー）/（categoryにあります） folder）/（virtual_env）/lib/python3.6/site-packages/mod_wsgi/server/mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so次のコマンドを使用します。
Sudo chcon system_u:object_r:httpd_modules_t:s0 (module filename)
完了すると、*。soディレクトリのls -Zで確認すると、*。soファイルは次のようになります。
-rwxrwx-x。ルートApache system_u：object_r：httpd_modules_t：s0（あなたのモジュール）
Root | Apacheを許可のために安全にするために設定しました。
私はすべてのDjangoファイルをmanage.pyファイルを除くApacheグループに設定しました。これは、root | rootとして保持します。
これで、selinuxを強制モードのままにして、Djangoアプリを、コンパイルしたmod_wsgiモジュールを使用してカスタムの場所で実行します。
皆さんのお役に立てば幸いです。遠慮なくコメントして、私たちをさらに教育してください。このコマンドを実行してselinuxの構成を確認することで、かなりの助けを得ました。
grep httpd /etc/selinux/targeted/contexts/files/file_contexts | less
Httpdに関連して事前設定されたオプションを確認できます。
この記事は非常に役に立ちました：