On Fri, Mar 5, 2021 at 12:21 AM Jacob Champion <pchamp...@vmware.com> wrote: > > On Thu, 2021-03-04 at 21:45 +0100, Magnus Hagander wrote: > > On Thu, Mar 4, 2021 at 9:07 PM Jacob Champion <pchamp...@vmware.com> wrote: > > > Idle thought I had while setting up a local test rig: Are there any > > > compelling cases for allowing PROXY packets to arrive over Unix > > > sockets? (By which I mean, the proxy is running on the same machine as > > > Postgres, and connects to it using the .s.PGSQL socket file instead of > > > TCP.) Are there cases where you want some other software to interact > > > with the TCP stack instead of Postgres, but it'd still be nice to have > > > the original connection information available? > > > > I'm uncertain what that usecase would be for something like haproxy, > > tbh. It can't do connection pooling, so adding it on the same machine > > as postgres itself wouldn't really add anything, I think? > > Yeah, I wasn't thinking HAproxy so much as some unspecified software > appliance that's performing Some Task before allowing a TCP client to > speak to Postgres. But it'd be better to hear from someone that has an > actual use case, instead of me spitballing. > > > Iid think about the other end, if you had a proxy on a different > > machine accepting unix connections and passing them on over > > PROXY-over-tcp. But I doubt it's useful to know it was unix in that > > case (since it still couldn't do peer or such for the auth) -- > > instead, that seems like an argument where it'd be better to proxy > > without using PROXY and just letting the IP address be. > > You could potentially design a system that lets you proxy a "local all > all trust" setup from a different (trusted) machine, without having to > actually let people onto the machine that's running Postgres. That > would require some additional authentication on the PROXY connection > (i.e. something stronger than host-based auth) to actually be useful. > > -- other notes -- > > A small nitpick on the current separate-port PoC is that I'm forced to > set up a "regular" TCP port, even if I only want the PROXY behavior.
Yeah. I'm not sure there's a good way to avoid that without making configuations a lot more complex. > The original-host logging isn't working for me: > > WARNING: pg_getnameinfo_all() failed: ai_family not supported > LOG: proxy connection from: host=??? port=??? > > and I think the culprit is this: > > > /* Store a copy of the original address, for logging */ > > memcpy(&raddr_save, &port->raddr, port->raddr.salen); > > port->raddr.salen is the length of port->raddr.addr; we want the length > of the copy to be sizeof(port->raddr) here, no? That's interesting -- it works perfectly fine here. What platform are you testing on? But yes, you are correct, it should do that. I guess it's a case of the salen actually ending up being uninitialized in the copy, and thus failing at a later stage. (I sent for sizeof(SockAddr) to make it easier to read without having to look things up, but the net result is the same) -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
