From: Jacob Champion <pchampion@vmware.com>
To: magnus@hagander.net <magnus@hagander.net>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: PROXY protocol support
Date: Thu, 4 Mar 2021 23:21:14 +0000
Message-ID: <d3a8e38c7a1c39034cbce45730456587b65479b1.camel@vmware.com> (raw)
In-Reply-To: <CABUevEy+aeHCCtKQMi38tvAjLfUq1Jf7fCpOB2z8V4g3y7Zrhg@mail.gmail.com>
References: <CABUevExJ0ifpUEiX4uOREy0s2kHBrBrb=pXLEHhpMTR1vVR1XA@mail.gmail.com>
<b097096a23f0c9ee5b4c8d97fcc4aa64ec3fc97c.camel@vmware.com>
<CABUevEwpMNDB7UGAS596wEu_OrvAdfzZ1tJJHNXsNWvofGOqrQ@mail.gmail.com>
<CABUevEzh6AoLxOvAoZf4WgNYoQv1OReb=2_XE49o-wturqUYvw@mail.gmail.com>
<955367547640a1e24a72d0e79236f49ec7f0dd21.camel@vmware.com>
<CABUevEy+aeHCCtKQMi38tvAjLfUq1Jf7fCpOB2z8V4g3y7Zrhg@mail.gmail.com>
On Thu, 2021-03-04 at 21:45 +0100, Magnus Hagander wrote:
> On Thu, Mar 4, 2021 at 9:07 PM Jacob Champion <pchampion@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.
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?
--Jacob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pchampion@vmware.com, magnus@hagander.net, pgsql-hackers@lists.postgresql.org
Subject: Re: PROXY protocol support
In-Reply-To: <d3a8e38c7a1c39034cbce45730456587b65479b1.camel@vmware.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox