Hello,
I'm trying to configure and run Django application behind Nginx reverse-proxy. My system is latest CentOS 7.2, SELinux is in Enforcing mode, selinux-policy-targeted-3.13.1-60.el7_2.7.noarch.
From audit.log messages I see, that SELinux prevent Nginx daemon access to socket file:
type=AVC msg=audit(1470659579.411:2693): avc: denied { write } for pid=34378 comm="nginx" name="gunicorn.sock" dev="dm-1" ino=921257 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1470659579.411:2693): arch=c000003e syscall=42 success=no exit=-13 a0=e a1=2513ce8 a2=6e a3=7ffd54ae92f0 items=0 ppid=34376 pid=34378 auid=4294967295 uid=992 gid=989 euid=992 suid=992 fsuid=992 egid=989 sgid=989 fsgid=989 tty=(none) ses=4294967295 comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1470659579.597:2694): avc: denied { write } for pid=34378 comm="nginx" name="gunicorn.sock" dev="dm-1" ino=921257 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=sock_file
Socket file is owned by Gunicorn user and has context usr_t, inherited from /opt/.* rule:
srwxrwxrwx. netbox nginx system_u:object_r:usr_t:s0 /opt/netbox/netbox/netbox/gunicorn.sock
From output of
# sesearch -A -s httpd_t | grep sock_file
I found rule that allows nginx (httpd_t) access to sock_file with httpd_var_run_t context:
allow httpd_t httpd_var_run_t : sock_file { ioctl read write create getattr setattr lock append unlink link rename open } ;
Next, I add that file context for my socket file location with s-filetype:
# semanage fcontext -a -f s -t httpd_var_run_t '/opt/netbox/netbox/netbox/gunicorn\.sock'
Removing and recreating socket file did not solve my problem - file still has a context usr_t :(
Gunicorn started by systemd and has context system_u:system_r:unconfined_service_t:s0
Furthermore, restorecon -v /opt/netbox/netbox/netbox/gunicorn.sock does not effect to applying httpd_var_run_t context to existing file!
I'm confused - I make something wrong or there is a bug in SELinux labeling?
Thanks for replies!
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
