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

From Andres Freund
Subject Re: Non-superuser subscription owners
Date
Msg-id 20230123015255.h3jro3yyitlsqykp@awork3.anarazel.de
Whole thread Raw
In response to Re: Non-superuser subscription owners  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Non-superuser subscription owners
List pgsql-hackers
Hi,

On 2023-01-22 09:05:27 -0800, Jeff Davis wrote:
> On Sat, 2023-01-21 at 14:01 -0800, Andres Freund wrote:
> > There are good reasons to have 'peer' authentication set up for the
> > user
> > running postgres, so admin scripts can connect without issues. Which
> > unfortunately then also means that postgres_fdw etc can connect to
> > the current
> > database as superuser, without that check. Which imo clearly is an
> > issue.
> 
> 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.


> > Why is this only about local files, rather than e.g. also using the local
> > user?
> 
> It's not, but we happen to already have pg_read_server_files, and it
> makes sense to use that at least for files referenced directly in the
> connection string. You're right that it's incomplete, and also that it
> doesn't make a lot of sense for files accessed indirectly.

I just meant that we need to pay attention to user-based permissions as well.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: run pgindent on a regular basis / scripted manner
Next
From: Justin Pryzby
Date:
Subject: Re: Remove source code display from \df+?