Re: Non-superuser subscription owners
От | Robert Haas |
---|---|
Тема | Re: Non-superuser subscription owners |
Дата | |
Msg-id | CA+TgmoZbFiYJWqxakw0fcNrPSPCqc_QnF8iCdXZqyM=d5jA-KA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Non-superuser subscription owners (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Non-superuser subscription owners
|
Список | 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 по дате отправления: