Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security
Date
Msg-id CAAWbhmhPFvV=TyGw0GfdLNUR6GMU0Ntcg6fEuhTNcha6f2oGig@mail.gmail.com
Whole thread Raw
In response to Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security  (Robert Haas <robertmhaas@gmail.com>)
Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Mar 8, 2023 at 11:40 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Mar 8, 2023 at 2:30 PM Jacob Champion <jchampion@timescale.com> wrote:
> > I don't think I necessarily like that option better than SASL-style,
> > but hopefully that clarifies it somewhat?
>
> Hmm, yeah, I guess that's OK.

Okay, cool.

> I still don't love it, though. It feels
> more solid to me if the proxy can actually block the connections
> before they even happen, without having to rely on a server
> interaction to figure out what is permissible.

Sure. I don't see a way for the proxy to figure that out by itself,
though, going back to my asymmetry argument from before. Only the
server truly knows, at time of HBA processing, whether the proxy
itself has authority. If the proxy knew, it wouldn't be confused.

> I don't know what you mean by SASL-style, exactly.

That's the one where the server explicitly names all forms of
authentication, including the ambient ones (ANONYMOUS, EXTERNAL,
etc.), and requires the client to choose one before running any
actions on their behalf. That lets the require_auth machinery work for
this case, too.

--Jacob



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: proposal - get_extension_version function
Next
From: Thomas Munro
Date:
Subject: Re: Add error functions: erf() and erfc()