On Wed, 2021-03-03 at 10:39 +0100, Magnus Hagander wrote: > On Wed, Mar 3, 2021 at 10:00 AM Magnus Hagander <mag...@hagander.net> wrote: > > Another option would of course be to listen on a separate port for it, > > which seems to be the "haproxy way". That would be slightly more code > > (we'd still want to keep the code for validating the list of trusted > > proxies I'd say), but maybe worth doing? > > In order to figure that out, I hacked up a poc on that. Once again > without updates to the docs, but shows approximately how much code > complexity it adds (not much).
From a configuration perspective, I like that the separate-port approach can shift the burden of verifying trust to an external firewall, and that it seems to match the behavior of other major server software. But I don't have any insight into the relative security of the two options in practice; hopefully someone else can chime in. > memset((char *) &hints, 0, sizeof(hints)); > hints.ai_flags = AI_NUMERICHOST; > hints.ai_family = AF_UNSPEC; > > ret = pg_getaddrinfo_all(tok, NULL, &hints, &gai_result); 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? --Jacob
