Nginx.http.sock recréé avec un contexte selinux incorrect

Soutien Installation
1

J’ai une instance Discourse placée derrière Apache via un proxy et communiquant via une socket, comme décrit ici.

SELinux est activé, donc pour accorder à httpd l’autorisation d’utiliser la socket, j’ai attribué à cette dernière un contexte où httpd dispose des permissions de lecture-écriture, comme conseillé :

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

Cela fonctionne. C’est excellent !

(Au passage : un contexte plus approprié ne serait-il pas httpd_var_run_t, étant donné que la socket elle-même n’est pas du contenu et que c’est le contexte utilisé par httpd pour les autres infrastructures d’exécution ?)

Cependant, chaque fois que le conteneur Discourse est redémarré, le fichier socket est recréé avec son contexte d’origine, et non le nouveau — je dois donc exécuter restorecon dessus avant qu’Apache puisse communiquer avec Discourse. Il est facile d’oublier de le faire et de se retrouver avec un forum inaccessible. J’ai pensé à utiliser un script cron pour exécuter restorecon périodiquement afin de ne pas avoir à le faire manuellement, mais c’est une solution peu élégante.

Comment puis-je m’assurer que le fichier socket obtient le contexte correct lors de sa création (ou du moins que son contexte est réinitialisé dans le cadre du processus de création) ?

2

Je créerais un script de redémarrage qui démarre le conteneur et modifie les permissions (et un autre qui effectue une reconstruction).

3

Ce qu’un script de redémarrage ne détecterait pas, c’est de procéder aux mises à niveau via le web depuis le panneau d’administration — c’est ce qui m’a joué un tour la dernière fois et m’a poussé à me demander s’il existait une solution valable pour tous les cas.

Je dois aussi préciser : je ne comprends pas pourquoi le socket ne reçoit pas le contexte correct lors de sa création. SELinux sait clairement quel devrait être le contexte par défaut pour le socket, comme le montre l’exécution de restorecon. (De plus, je peux voir l’entrée pour le socket, générée par l’exécution de semanage fcontext, dans /etc/selinux/targeted/contexts/files/file_contexts.local.)