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 1ipeHz-0003Bb-Nf for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jan 2020 20:20:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ipeH0-0000it-Az for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jan 2020 20:19:18 +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 1ipeGL-0005Xc-NL for pgsql-hackers@lists.postgresql.org; Thu, 09 Jan 2020 20:18:37 +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 1ipeGJ-0005NJ-Fl for pgsql-hackers@lists.postgresql.org; Thu, 09 Jan 2020 20:18:37 +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 009KIUHp011274; Thu, 9 Jan 2020 15:18:30 -0500 From: Tom Lane To: Stephen Frost cc: Robert Haas , Peter Eisentraut , PostgreSQL Hackers Subject: Re: Removing pg_pltemplate and creating "trustable" extensions In-reply-to: <20200109200028.GX3195@tamriel.snowman.net> References: <20200108003247.GE3195@tamriel.snowman.net> <20200108230935.GN3195@tamriel.snowman.net> <20200109150911.GP3195@tamriel.snowman.net> <20200109163013.GR3195@tamriel.snowman.net> <6440.1578594907@sss.pgh.pa.us> <20200109200028.GX3195@tamriel.snowman.net> Comments: In-reply-to Stephen Frost message dated "Thu, 09 Jan 2020 15:00:28 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11272.1578601110.1@sss.pgh.pa.us> Date: Thu, 09 Jan 2020 15:18:30 -0500 Message-ID: <11273.1578601110@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Stephen Frost writes: > So I'm at a loss for why there is this insistence on a default role and > a superuser-explicit-granting based approach that goes beyond "is it > installed on the filesystem?" and "is it marked as trusted?". Okay, so it seems like we're down to just this one point of contention. You feel that the superuser can control what is in the extension library directory and that that ought to be sufficient control. I disagree with that, for two reasons: * ISTM that that's assuming that the DBA and the sysadmin are the same person (or at least hold identical views on this subject). In many installations it'd only be root who has control over what's in that directory, and I don't think it's unreasonable for the DBA to wish to be able to exercise additional filtering. * The point of a default role would be for the DBA to be able to control which database users can install extensions. Even if the DBA has full authority over the extension library, that would not provide control over who can install, only over what is available for any of them to install. regards, tom lane