시스템 사용자 단위를 시작하려고 합니다. 이 장치는 포트 바인딩을 시도하는 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 연결에서 수행되었습니다.