システムユーザーユニットを起動しようとしています。このデバイスはポートバインディングを試みる Podman コンテナです。
を実行すると、systemctl --user start my-serviceコンテナは正常に起動します。
実行するとsh -c 'systemctl --user start my-service'（脚注を参照）、SELinuxエラーのためコンテナは起動しません。
***** Plugin catchall (100. confidence) suggests **************************
If you believe that a-service should be allowed create access on the port None tcp_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'a-service' --raw | audit2allow -M my-aservice
# semodule -X 300 -i my-aservice.pp
指定されたポリシー変更の実行確かに問題を解決する。無効にして実施するsetenforce 0 する、これがSELinuxの問題であると確信しています。実際に内部でコンテナを直接起動すると、sh -c 'podman run ...'別のSELinuxエラーが発生するため、ポリシーの更新を追跡するのがうまくいっても、実際のソリューションだとは思わない。
私の考えでは、これがポリシーなどを継承しないサブシェル作成の影響のようです。どうすれば解決できますか？ SELinuxを無効にしたくありません。
export両方のシェル（親とネスト）の環境が表示されますが、SELINUX_[ROLE|LEVEL]_REQUESTED=""インターネット検索ではこれらの環境変数の結果は表示されず、マニュアルページでも見つかりません。
このユーザーはのメンバーですwheel。システムはCentOS 9 Stream。
私が知る限り、サブシェルには次の良い（？）戦略がありますunconfined_*。
[deploy@host ~]$ sh -c 'ps -eZ' | grep ps
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 24356 pts/0 00:00:00 ps
pyinfra設定されたSSH接続を介して直接実行するのではなく、コマンドを実行するvia経由で展開しているため、sh -c '...'「新しいシェルを作成しない」オプションはありません。ただし、上記の例は「生」のSSH接続で行われました。