How can I tell SELinux to permit nginx access to a unix socket without audit2allow?

drs asked:

I have nginx forwarding requests to gunicorn via a unix socket at /run/gunicorn/socket. By default, this behavior is not permitted by SELinux:

grep nginx /var/log/audit/audit.log
type=SERVICE_START msg=audit(1454358912.455:5390): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=nginx comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1454360194.623:7324): avc:  denied  { write } for  pid=9128 comm="nginx" name="socket" dev="tmpfs" ino=76151 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1454360194.623:7324): arch=c000003e syscall=42 success=no exit=-13 a0=c a1=1f6fe58 a2=6e a3=7ffee1da5710 items=0 ppid=9127 pid=9128 auid=4294967295 uid=995 gid=993 euid=995 suid=995 fsuid=995 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1454361591.701:13343): avc:  denied  { connectto } for  pid=9128 comm="nginx" path="/run/gunicorn/socket" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
type=SYSCALL msg=audit(1454361591.701:13343): arch=c000003e syscall=42 success=no exit=-13 a0=c a1=1f6fe58 a2=6e a3=7ffee1da5950 items=0 ppid=9127 pid=9128 auid=4294967295 uid=995 gid=993 euid=995 suid=995 fsuid=995 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0 key=(null)

Everywhere I look (e.g., here and here), the instructions to enable this say to make a request to nginx, have the request be denied by SELinux, then run audit2allow to permit future requests. I can’t figure out any chcon or semanage command that allows this behavior explicitly.

Is this the only way? It seems ridiculous that you can’t set up a policy that allows nginx to write to a socket without first having an attempt denied and then running a tool that enables things that were denied. How do you know exactly what is being enabled? How is this supposed to work if your setting up machines under automation?

I’m using CentOS 7.

My answer:


The type you want to use is not httpd_sys_content_t. This is for static files that the web server is meant to serve to user agents.

For a socket used for interprocess communication, the type you are looking for is httpd_var_run_t.

Though, please note that because you ran gunicorn unconfined, there may be additional issues communicating with it.


View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.