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 CAAWbhmg25XaA=s04y7_LK8Q7-GSBw09fH2A5iiFESUbVaFXWqg@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>)
List pgsql-hackers
On Tue, Mar 7, 2023 at 11:04 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Feb 9, 2023 at 4:46 PM Jacob Champion <jchampion@timescale.com> wrote:
> > On 2/6/23 08:22, Robert Haas wrote:
> > > I don't think that's quite the right concept. It seems to me that the
> > > client is responsible for informing the server of what the situation
> > > is, and the server is responsible for deciding whether to allow the
> > > connection. In your scenario, the client is not only communicating
> > > information ("here's the password I have got") but also making demands
> > > on the server ("DO NOT authenticate using anything else"). I like the
> > > first part fine, but not the second part.
> >
> > For what it's worth, making a negative demand during authentication is
> > pretty standard: if you visit example.com and it tells you "I need your
> > OS login password and Social Security Number to authenticate you," you
> > have the option of saying "no thanks" and closing the tab.
>
> No, that's the opposite, and exactly the point I'm trying to make. In
> that case, the SERVER says what it's willing to accept, and the CLIENT
> decides whether or not to provide that. In your proposal, the client
> tells the server which authentication methods to accept.

Ah, that's a (the?) sticking point. In my example, the client doesn't
tell the server which methods to accept. The client tells the server
which method the *client* has the ability to use. (Or, implicitly,
which methods it refuses to use.)

That shouldn't lose any power, security-wise, because the server is
looking for an intersection of the two sets. And the client already
has the power to do that for almost every form of authentication,
except the ambient methods.

I don't think I necessarily like that option better than SASL-style,
but hopefully that clarifies it somewhat?

> I don't think we're really very far apart here, but for some reason
> the terminology seems to be giving us some trouble.

Agreed.

> Of course, there's
> also the small problem of actually finding the time to do some
> meaningful work on this stuff, rather than just talking....

Agreed :)

--Jacob



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Add shared buffer hits to pg_stat_io
Next
From: Robert Haas
Date:
Subject: Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security