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

Installation
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. :relaxed:

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 Likes
2

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

3 Likes
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.

3 Likes
5

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