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 1ixXz7-0005tQ-J0 for pgsql-hackers@arkaria.postgresql.org; Fri, 31 Jan 2020 15:13:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ixXz6-0007gK-5y for pgsql-hackers@arkaria.postgresql.org; Fri, 31 Jan 2020 15:13:28 +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 1ixXz5-0007e9-Td for pgsql-hackers@lists.postgresql.org; Fri, 31 Jan 2020 15:13:27 +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 1ixXz3-00043B-33 for pgsql-hackers@lists.postgresql.org; Fri, 31 Jan 2020 15:13:27 +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 00VFDJ3Y023118; Fri, 31 Jan 2020 10:13:19 -0500 From: Tom Lane To: Dean Rasheed cc: Julien Rouhaud , =?UTF-8?Q?Darafei_Kom=D1=8Fpa_Praliaskouski?= , PostgreSQL Developers Subject: Re: Marking some contrib modules as trusted extensions In-reply-to: References: <32315.1580326876@sss.pgh.pa.us> <5280.1580333933@sss.pgh.pa.us> Comments: In-reply-to Dean Rasheed message dated "Fri, 31 Jan 2020 09:40:32 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23116.1580483599.1@sss.pgh.pa.us> Date: Fri, 31 Jan 2020 10:13:19 -0500 Message-ID: <23117.1580483599@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Dean Rasheed writes: > On Wed, 29 Jan 2020 at 21:39, Tom Lane wrote: >> The bigger picture here is that I don't want to get push-back that >> we've broken somebody's security posture by marking too many extensions >> trusted. So for anything where there's any question about security >> implications, we should err in the conservative direction of leaving >> it untrusted. > I wonder if the same could be said about pgrowlocks. Good point. I had figured it was probably OK given that it's analogous to the pg_locks view (which is unrestricted AFAIR), and that it already has some restrictions on what you can see. I'd have no hesitation about dropping it off this list though, since it's probably not used that much and it could also be seen as exposing internals. regards, tom lane