我正在尝试启动一个 systemd 用户单元。该单元是一个尝试绑定端口的 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 错误，所以我不认为追逐策略更新是真正的解决方案 - 即使它们有效。
我认为这是生成不继承策略或其他内容的子 shell 的一些影响，我该如何解决这个问题？我不想禁用 SELinux。
export两个 shell（顶部和嵌套）的环境都显示，SELINUX_[ROLE|LEVEL]_REQUESTED=""但谷歌搜索没有显示这些环境变量的结果，我也无法在手册页中找到它。
该用户是 的成员wheel。该系统是CentOS 9 Stream.
据我所知，子 shell 具有以下好的（？）策略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
- 我正在部署 via
pyinfra，它通过 执行其命令sh -c '...'，而不是直接通过已建立的 ssh 连接，所以我没有“不生成新 shell”的选项。不过，上面的示例是在“原始”ssh 连接上执行的。