Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1myG56-0003KR-71 for pgsql-sql@arkaria.postgresql.org; Fri, 17 Dec 2021 16:27:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1myG54-0005Qa-76 for pgsql-sql@arkaria.postgresql.org; Fri, 17 Dec 2021 16:27:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1myG53-0005QR-UL for pgsql-sql@lists.postgresql.org; Fri, 17 Dec 2021 16:27:37 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1myG51-0000F9-IG for pgsql-sql@lists.postgresql.org; Fri, 17 Dec 2021 16:27:36 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 1BHGRURv1355150; Fri, 17 Dec 2021 11:27:30 -0500 From: Tom Lane To: Jonathan Katz cc: aditya desai , pgsql-sql Subject: Re: Pragma autonomous transactions in Postgres/ Certification based authentication in DB Links In-reply-to: References: Comments: In-reply-to Jonathan Katz message dated "Fri, 17 Dec 2021 11:11:55 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1355148.1639758450.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Dec 2021 11:27:30 -0500 Message-ID: <1355149.1639758450@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Jonathan Katz writes: >> On Dec 17, 2021, at 10:43 AM, aditya desai wrote: >> How to use certificate based authentication in DB Links instead of hard= coding user name and password in it? > dblink lets you pass in a PostgreSQL connection string[1]. > From there you can reference parameters to use certificates[2]. 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. Maybe "use server's FDW credentials" could be associated with a grantable role? That's still an awfully coarse-grained approach though. I thought for a moment about putting an SSL cert right into the connection string; but you'd have to put the SSL private key in there too, making it just as much of a security problem as putting a password there (but about 100 times more verbose :-(). regards, tom lane [1] https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dblob;f=3Dcon= trib/dblink/dblink.c;h=3Dd73c616f4f240cf5f33294e61053765375a5bea6;hb=3DHEA= D#l2669 [2] https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dblob;f=3Dcon= trib/dblink/dblink.c;h=3Dd73c616f4f240cf5f33294e61053765375a5bea6;hb=3DHEA= D#l2690