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: Wed, 14 Jul 2021 18:23:59 +0000
Message-ID: <0c4b20fd6b33e21f3776cac88219920cac73a883.camel@vmware.com> (raw)
In-Reply-To: <CABUevEwHUmYBXDvOWjN1wcn4mfZ1h1rwvg2AWYS9kD4ycykYFw@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>
<d3a8e38c7a1c39034cbce45730456587b65479b1.camel@vmware.com>
<CABUevExYtq2xuJXUWUCYMR12TwEcT8ODhn2n3Le09KeayXdegA@mail.gmail.com>
<fafc3f393dd968dfbe71ca98a034472f4fbeeb15.camel@vmware.com>
<CABUevEygBkZWyw0qYt8pMZ4jp3DOjMYKoj-68T_qFjeYqoi+6g@mail.gmail.com>
<CABUevEy9MP0THCJNOb4NN8aQ3La40=ah3gKbYvoAmUs1hjknzw@mail.gmail.com>
<CABUevEzE9FZfjc7ZS=iHzaw+8GFcFjzA7AqEyZ9fBJt=rkgj-A@mail.gmail.com>
<d802f0761898a9efcd1a3181247717e458d219b0.camel@vmware.com>
<CABUevEwJK52jqoXQOhGr2-6bA+MG3sFfELfPJ4hDGFoyH-orWA@mail.gmail.com>
<8aeede56330ca5721265428302c7f73e4e2e1264.camel@vmware.com>
<CABUevEwHUmYBXDvOWjN1wcn4mfZ1h1rwvg2AWYS9kD4ycykYFw@mail.gmail.com>
On Mon, 2021-07-12 at 18:28 +0200, Magnus Hagander wrote:
> Yeah, I have no problem being stricter than necessary, unless that
> actually causes any interop problems. It's a lot worse to not be
> strict enough..
Agreed. Haven't heard back from the HAProxy mailing list yet, so
staying strict seems reasonable in the meantime. That could always be
rolled back later.
> > I've been thinking more about your earlier comment:
> >
> > > An interesting thing is what to do about
> > > inet_server_addr/inet_server_port. That sort of loops back up to the
> > > original question of where/how to expose the information about the
> > > proxy in general (since right now it just logs). Right now you can
> > > actually use inet_server_port() to see if the connection was proxied
> > > (as long as it was over tcp).
> >
> > IMO these should return the "virtual" dst_addr/port, instead of
> > exposing the physical connection information to the client. That way,
> > if you intend for your proxy to be transparent, you're not advertising
> > your network internals to connected clients. It also means that clients
> > can reasonably expect to be able to reconnect to the addr:port that we
> > give them, and prevents confusion if the proxy is using an address
> > family that the client doesn't even support (e.g. the client is IPv4-
> > only but the proxy connects via IPv6).
>
> That reasoning I think makes a lot of sense, especially with the
> comment about being able to connect back to it.
>
> The question at that point extends to, would we also add extra
> functions to get the data on the proxy connection itself? Maybe add a
> inet_proxy_addr()/inet_proxy_port()? Better names?
What's the intended use case? I have trouble viewing those as anything
but information disclosure vectors, but I'm jaded. :)
If the goal is to give a last-ditch debugging tool to someone whose
proxy isn't behaving properly -- though I'd hope the proxy in question
has its own ways to debug its behavior -- maybe they could be locked
behind one of the pg_monitor roles, so that they're only available to
someone who could get that information anyway?
> PFA a patch that fixes the above errors, and changes
> inet_server_addr()/inet_server_port(). Does not yet add anything to
> receive the actual local port in this case.
Looking good in local testing. I'm going to reread the spec with fresh
eyes and do a full review pass, but this is shaping up nicely IMO.
Something that I haven't thought about very hard yet is proxy
authentication, but I think the simple IP authentication will be enough
for a first version. For the Unix socket case, it looks like anyone
currently relying on peer auth will need to switch to a
unix_socket_group/_permissions model. For now, that sounds like a
reasonable v1 restriction, though I think not being able to set the
proxy socket's permissions separately from the "normal" one might lead
to some complications in more advanced setups.
--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: <0c4b20fd6b33e21f3776cac88219920cac73a883.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