This strace output shows what haproxy is up to when it fails:
464   00:52:09.832823 chown("/var/run/haproxy.sock.464.tmp", 188, 4294967295) = 0 <0.000081>
464   00:52:09.833261 chmod("/var/run/haproxy.sock.464.tmp", 0755) = -1 EPERM (Operation not permitted) <0.000466> <----- here
464   00:52:09.833829 unlink("/var/run/haproxy.sock.464.tmp") = 0 <0.000041>
464   00:52:09.833950 close(4)          = 0 <0.000105>
464   00:52:09.834119 unlink("/var/run/haproxy.sock.464.bak") = -1 ENOENT (No such file or directory) <0.000040>
464   00:52:09.834293 write(2, "[ALERT] 291/005149 (464) : ", 27) = 27 <0.000589>
464   00:52:09.835018 write(2, "Starting frontend GLOBAL: cannot change UNIX socket ownership [/var/run/haproxy.sock]\n", 86) = 86 <0.001536>

And this is where it happens in src/proto_uxst.c:

        if (!ext && path[0] && 
            (((listener->bind_conf->ux.uid != -1 || listener->bind_conf->ux.gid != -1) &&
              (chown(tempname, listener->bind_conf->ux.uid, listener->bind_conf->ux.gid) == -1)) ||
             (listener->bind_conf->ux.mode != 0 && chmod(tempname, listener->bind_conf->ux.mode) == -1))) {
                err |= ERR_FATAL | ERR_ALERT;
                msg = "cannot change UNIX socket ownership";
                goto err_unlink_temp;
        }

Accidentally, I found out that file context pattern for the /var/run/haproxy.sock socket is incorrect:

# semanage fcontext -l | grep '/var/run/haproxy.*sock'
/var/run/haproxy\.sock.*                           regular file       system_u:object_r:haproxy_var_run_t:s0 
# ls -l /var/run/haproxy.sock 
srwxr-xr-x. 1 haproxy root 0 Oct 18 16:40 /var/run/haproxy.sock
# matchpathcon /var/run/haproxy.sock 
/var/run/haproxy.sock	system_u:object_r:var_run_t:s0
# rm -f /var/run/haproxy.sock
# matchpathcon /var/run/haproxy.sock 
/var/run/haproxy.sock	system_u:object_r:haproxy_var_run_t:s0
# 

The file context pattern matches only regular files, but it should match sockets:

# semanage fcontext -l | grep '/var/run/haproxy.*sock'
/var/run/haproxy\.sock.*                           socket       system_u:object_r:haproxy_var_run_t:s0 
#

Milosi,

Once the daemon manages to start, the socket file context looks like the correct one, either it is in /var/run or /var/lib/haproxy directory:

  $ ls -lZ /var/run/haproxy.sock /var/lib/haproxy/haproxy2.sock
srwxr-xr-x. root root system_u:object_r:haproxy_var_lib_t:s0 /var/lib/haproxy/haproxy2.sock
srwxr-xr-x. root root system_u:object_r:haproxy_var_run_t:s0 /var/run/haproxy.sock

Not quite sure if it is related, but the files are actually created in the /run directory which is a tmpfs linked to from /var/run. The policy does not seem to contain any reference to ^/run.

RHEL-6 and RHEL-7 support a feature called  file context equivalences which define that /run will be treated the same way as /var/run:

# semanage fcontext -l | grep -A 100 -i equivalence
SELinux Distribution fcontext Equivalence 

/usr/local/lib64 = /usr/lib
/etc/systemd/system = /usr/lib/systemd/system
/run/systemd/system = /usr/lib/systemd/system
/run/systemd/generator = /usr/lib/systemd/system
/var/home = /home
/var/roothome = /root
/usr/lib64 = /usr/lib
/var/lib/xguest/home = /home
/var/named/chroot/lib64 = /usr/lib
/var/named/chroot/usr/lib64 = /usr/lib
/run = /var/run
/usr/local/lib32 = /usr/lib
/lib64 = /usr/lib
/lib = /usr/lib
/run/lock = /var/lock
#

This feature is heavily used by RHSCL components.

Could we confirm if this is a simple selinux policy that needs corrected?  Or does it need updated to use the file context equivalence as noted in cmt6?

(In reply to Terry Bowling from comment #7)
> Could we confirm if this is a simple selinux policy that needs corrected? 
> Or does it need updated to use the file context equivalence as noted in cmt6?

According to comment#4 we should update haproxy context file policy.

Thanks guys for investigation.

I set a non-root group on the haproxy socket file and are also affected by this. This prevents HAProxy from being reloaded and can also prevent haproxy from starting. I sometimes have to manually remove the socket file before I can start HAProxy.

This is in my audit.log.
---
type=AVC msg=audit(1485174334.322:170648): avc:  denied  { link } for  pid=62485 comm="haproxy" name="haproxy.sock" dev="tmpfs" ino=57340817 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file

type=AVC msg=audit(1485175066.360:171290): avc:  denied  { fsetid } for  pid=65435 comm="haproxy" capability=4  scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:system_r:haproxy_t:s0 tclass=capability
---

The first denial is caused by having the wrong file context (var_run_t in stead of haproxy_var_run_t), but the second I am not sure.

Perhaps the second one is a missing permission for the HAProxy process?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1861