From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Kellerer <shammat@gmx.net>
cc: pgsql-sql@lists.postgresql.org
Subject: Re: Pragma autonomous transactions in Postgres/ Certification based
 authentication in DB Links
In-reply-to: <b1c37523-c7ec-1643-4958-e7c8f400e3a8@gmx.net>
References: 
 <CAN0SRDEGsXnULFzB+X7FNzwO4iT27G=rDhe9GgvMnhsj98KKPw@mail.gmail.com>
 <A0E82030-D418-4596-A6E5-87016B0CCCE7@excoventures.com>
 <1355149.1639758450@sss.pgh.pa.us>
 <b1c37523-c7ec-1643-4958-e7c8f400e3a8@gmx.net>
Comments: In-reply-to Thomas Kellerer <shammat@gmx.net>
	message dated "Fri, 17 Dec 2021 18:07:29 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1364138.1639763935.1@sss.pgh.pa.us>
Date: Fri, 17 Dec 2021 12:58:55 -0500
Message-ID: <1364139.1639763935@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1364139.1639763935%40sss.pgh.pa.us>
Precedence: bulk

Thomas Kellerer <shammat@gmx.net> writes:
> Tom Lane schrieb am 17.12.2021 um 17:27:
>> No, that won't help.  Like postgres_fdw, dblink will only let you use
>> non-password auth methods if you're superuser [1][2].  The problem is
>> that making use of any credentials stored in the server's filesystem
>> amounts to impersonating the OS user that's running the server.  It'd
>> be nice to find a less confining solution, but I'm not sure what one
>> would look like.

> What about using a .pgpass file?

Still amounts to impersonating the server (and yeah, we do prevent
that if you're not superuser).

It might make sense to have a superuser-owned SECURITY DEFINER
function that's responsible for creating the desired connection,
and could make use of the server's .pgpass credentials.  As long
as you restrict what that function is willing to do, and restrict
who can execute it, this'd probably be adequately secure.

			regards, tom lane