Re: Non-superuser subscription owners - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Non-superuser subscription owners
Date
Msg-id CA+TgmoZbFiYJWqxakw0fcNrPSPCqc_QnF8iCdXZqyM=d5jA-KA@mail.gmail.com
Whole thread Raw
In response to Re: Non-superuser subscription owners  (Andres Freund <andres@anarazel.de>)
Responses Re: Non-superuser subscription owners
List pgsql-hackers
On Sun, Jan 22, 2023 at 8:52 PM Andres Freund <andres@anarazel.de> wrote:
> > Perhaps we should have a way to directly turn on/off authentication
> > methods in libpq through API functions and/or options?
>
> Yes. There's an in-progress patch adding, I think, pretty much what is
> required here:
> https://www.postgresql.org/message-id/9e5a8ccddb8355ea9fa4b75a1e3a9edc88a70cd3.camel@vmware.com
>
> require_auth=a,b,c
>
> I think an allowlist approach is the right thing for the subscription (and
> postgres_fdw/dblink) use case, otherwise we'll add some auth method down the
> line without updating what's disallowed in the subscription code.

So what would we do here, exactly? We could force a require_auth
parameter into the provided connection string, although I'm not quite
sure of the details there, but what value should we force? Is that
going to be something hard-coded, or something configurable? If
configurable, where does that configuration get stored?

Regardless, this only allows connection strings to be restricted along
one axis: authentication type. If you want to let people connect only
to a certain subnet or whatever, you're still out of luck.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: run pgindent on a regular basis / scripted manner
Next
From: Andres Freund
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?