Nginx.http.sock recreated with incorrect selinux context

installation
1

I have a Discourse instance proxied behind Apache and communicating over a socket, as described here.

I have SELinux enabled, so in order to give httpd permission to use the socket, I’ve given the socket a context where httpd has read-write permission, as advised:

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

This works. It’s great!

(Aside: Would a more appropriate context be httpd_var_run_t, as the socket itself isn’t content and this is the context used by httpd for other runtime infrastructure?)

However, whenever the Discourse container is restarted the socket file is recreated with its original context, not the new one—hence I have to restorecon it before Apache can talk to Discourse. It’s easy to forget to do this and end up with an inaccessible forum. It occurred to me that I could use a cron script to run restorecon periodically so I don’t have to remember to do it manually, but that’s an ugly hack.

How can I ensure that the socket file gets the correct context on creation (or at least has its context reset as part of the creation process)?

2

I’d make a restart script that started the container and changed the permission (and another that does a rebuild).

3

The thing a restart script wouldn’t catch is doing upgrades via the web from the admin panel—that’s what got me last time and prompted me to wonder if there were a fix for all cases.

I should also say: I don’t understand why the socket doesn’t get the correct context on creation. SELinux clearly knows what the default context for the socket should be, as running restorecon shows. (Also, I can see the entry for the socket made from running semanage fcontext in /etc/selinux/targeted/contexts/files/file_contexts.local.)