Any downsides to proxy via port instead of unix domain socket?

Product Support Self-hosting

AI-generated summary

mcdanlj is testing Discourse on AlmaLinux 9 with SELinux enabled and external nginx. Due to SELinux issues with Unix domain sockets, they are considering proxying to a network port instead. They have made it work by setting httpd_can_network_connect to 1, exposing port 8008, and updating the external nginx configuration.

Falco noted that as long as direct connections to port 8008 are blocked, this setup should not be a problem.

Stephen pointed out that there is a difference in latency between using a socket and a local loopback port, with sockets being around 3 times quicker. However, the actual difference in latency is very small (around 4-5 microseconds).

mcdanlj plans to add proxy_set_header "Connection" ""; to disable the default Connection: close header. They will write up more detailed documentation after thorough testing.

1

I’m testing deploying Discourse on top of the CentOS-derived AlmaLinux 9 with SELinux enabled and external nginx configured.

Because the Ubuntu-based container doesn’t know about SELinux, it keeps replacing the unix domain socket with a new file that is not security labeled every time I start the container, and nginx isn’t allowed to talk to it until I restorecon the file to give it a security context that nginx is allowed to access. Obviously that doesn’t work as a production solution.

I don’t really want to semanage permissive -a httpd_t because I’d like to actually take advantage of SELinux on the one service that’s actually open to the outside world. :smiling_face:

It works if I proxy to a network port instead of to a unix domain socket:

  • setsebool -P httpd_can_network_connect 1
  • do not use templates/web.socketed.template.yml
  • `expose: - “8008:80”
  • In the external nginx, proxy_pass http://127.0.0.1:8008

Are there any particular downsides to this? Ought I to change any parameters like connection limiting in this configuration?

I’ll write this up in more detail as documentation after more thorough testing, and if there are additional concerns I can include that in what I write up.

2

As long as you block people from connecting directly to port 8008 using your preferred method, no problem.

3

Thanks!

public (active)
  target: default
...
  services: dhcpv6-client http https ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:
4

There is a difference in latency, a socket is about ~3x quicker than a local loopback port.

That said, we’re talking a difference of 4-5us here at best.

5

After looking into this more, I definitely want to add proxy_set_header "Connection" ""; to disable the default Connection: close header