Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ipfsu-0006n5-Mv for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jan 2020 22:02:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ipfst-0007QF-AE for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jan 2020 22:02:31 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ipfst-0007Q8-1G for pgsql-hackers@lists.postgresql.org; Thu, 09 Jan 2020 22:02:31 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ipfsm-0006mQ-1l for pgsql-hackers@lists.postgresql.org; Thu, 09 Jan 2020 22:02:30 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id 009M2Ict017449; Thu, 9 Jan 2020 17:02:18 -0500 From: Tom Lane To: Andrew Dunstan cc: Robert Haas , Christoph Berg , PostgreSQL Hackers Subject: Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings In-reply-to: References: <20200109103014.GA4192@msg.df7cb.de> Comments: In-reply-to Andrew Dunstan message dated "Fri, 10 Jan 2020 08:08:42 +1030" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17447.1578607338.1@sss.pgh.pa.us> Date: Thu, 09 Jan 2020 17:02:18 -0500 Message-ID: <17448.1578607338@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andrew Dunstan writes: > On Fri, Jan 10, 2020 at 1:21 AM Robert Haas wrote: >> I share the concern about the security issue here. I can't testify to >> whether Christoph's whole analysis is here, but as a general point, >> non-superusers can't be allowed to do things that cause the server to >> access arbitrary local files. > It's probably fairly easy to do (c.f. 6136e94dcb). I'm not (yet) > convinced that there is any significant security threat here. This > doesn't give the user or indeed any postgres code any access to the > contents of these files. But if there is a consensus to restrict this > I'll do it. Well, even without access to the file contents, the mere ability to probe the existence of a file is something we don't want unprivileged users to have. And (I suppose) this is enough for that, by looking at what error you get back from trying it. regards, tom lane