nginx.http.sock가 잘못된 SELinux 컨텍스트로 재생성됨

Apache 뒤에서 소켓을 통해 통신하는 Discourse 인스턴스를 운영 중이며, 여기에 설명된 대로 설정되어 있습니다.

SELinux가 활성화되어 있어 httpd가 소켓을 사용할 수 있도록 권한을 부여해야 합니다. 조언에 따라 httpd가 읽기/쓰기 권한을 가진 컨텍스트를 소켓에 부여했습니다:

semanage fcontext -a -t httpd_sys_rw_content_t /var/discourse/shared/standalone/nginx.http.sock
restorecon /var/discourse/shared/standalone/nginx.http.sock

이렇게 하면 잘 작동합니다. 아주 좋습니다!

(참고: 소켓 자체가 _콘텐츠_가 아니므로, httpd가 다른 런타임 인프라에 사용하는 컨텍스트인 httpd_var_run_t가 더 적절한 컨텍스트가 아닐까요?)

하지만 Discourse 컨테이너가 재시작될 때마다 소켓 파일은 원래 컨텍스트로 재생성됩니다. 새로운 컨텍스트가 적용되지 않는 것이죠. 따라서 Apache가 Discourse와 통신하려면 항상 restorecon을 실행해야 합니다. 이 작업을 잊어버리기 쉽기 때문에 포럼에 접근할 수 없는 상황이 생길 수 있습니다. 수동으로 기억해야 하는 번거로움을 피하기 위해 cron 스크립트로 주기적으로 restorecon을 실행하는 방법도 떠올랐지만, 이는 보기 흉한 해킹(hack)에 불과합니다.

소켓 파일이 생성될 때 올바른 컨텍스트가 적용되도록(최소한 생성 과정의 일부로 컨텍스트가 재설정되도록) 보장하는 방법은 무엇일까요?

컨테이너를 시작하고 권한을 변경하는 리스타트 스크립트(그리고 리빌드를 수행하는 또 다른 스크립트)를 만들겠습니다.

재시작 스크립트가 포착하지 못하는 경우는 관리자 패널을 통해 웹으로 업그레이드를 수행하는 것입니다. 지난번에는 이 부분이 문제를 일으켜서, 모든 경우에 적용 가능한 해결책이 있는지 궁금해졌습니다.

또한 한 가지 더 말씀드리자면: 소켓이 생성될 때 왜 올바른 컨텍스트를 받지 못하는지 이해하지 못하겠습니다. SELinux는 소켓의 기본 컨텍스트가 무엇인지 분명히 알고 있습니다. restorecon을 실행하면 그걸 알 수 있으니까요. (또한, semanage fcontext를 실행하여 만든 소켓의 항목을 /etc/selinux/targeted/contexts/files/file_contexts.local에서 볼 수 있습니다.)