pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
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, 8 Sep 2021 18:51:27 +0000
Message-ID: <84af2549930307353eea7422decf910dbcffb334.camel@vmware.com> (raw)
In-Reply-To: <CABUevEw-yjGqrH6g7jv5R+vabjnisCteJ7KY2n1ouQ8E8g1V+A@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>
	<0c4b20fd6b33e21f3776cac88219920cac73a883.camel@vmware.com>
	<CABUevEw-yjGqrH6g7jv5R+vabjnisCteJ7KY2n1ouQ8E8g1V+A@mail.gmail.com>

On Tue, 2021-09-07 at 12:24 +0200, Magnus Hagander wrote:
> On Wed, Jul 14, 2021 at 8:24 PM Jacob Champion <pchampion@vmware.com> wrote:
> > 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.
> 
> Any further feedback from them now, two months later? :)

Not yet :( I've bumped the thread; in the meantime I still think the
stricter operation is fine, since in the worst case you just make it
less strict in the future.

> (Sorry, I was out on vacation for the end of the last CF, so didn't
> get around to this one, but it seemed there'd be plenty of time in
> this CF)

No worries!

> > > 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. :)
> 
> "Covering all the bases"?
> 
> I'm not entirely sure what the point is of the *existing* functions
> for that though, so I'm definitely not wedded to including it.

I guess I'm in the same boat. I'm probably not the right person to
weigh in.

> > 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.
> 
> Thanks!

I still owe you that overall review. Hoping to get to it this week.

> > 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.
> 
> Agreed in principle, but I think those are some quite uncommon
> usecases, so definitely something we don't need to cover in a first
> feature.

Hm. I guess I'm overly optimistic that "properly securing your
database" is not such an uncommon case, but... :)

--Jacob


view thread (56+ messages)  latest in thread

Message-ID: <84af2549930307353eea7422decf910dbcffb334.camel@vmware.com>
Permalink:  ../84af2549930307353eea7422decf910dbcffb334.camel@vmware.com/
Also on:    postgresql.org/message-id/84af2549930307353eea7422decf910dbcffb334.camel@vmware.com

 · 

reply

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: <84af2549930307353eea7422decf910dbcffb334.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