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 1iq39h-00017N-Or for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jan 2020 22:53:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iq39f-0001C8-Dy for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jan 2020 22:53:23 +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 1iq39f-0001B4-51 for pgsql-hackers@lists.postgresql.org; Fri, 10 Jan 2020 22:53:23 +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 1iq39X-0001wK-RY for pgsql-hackers@lists.postgresql.org; Fri, 10 Jan 2020 22:53:22 +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 00AMrAtT027619; Fri, 10 Jan 2020 17:53:10 -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: <20200110205003.GD3195@tamriel.snowman.net> References: <20200109163013.GR3195@tamriel.snowman.net> <6440.1578594907@sss.pgh.pa.us> <9933.1578599320@sss.pgh.pa.us> <12039.1578602021@sss.pgh.pa.us> <20200110192646.GZ3195@tamriel.snowman.net> <16979.1578685198@sss.pgh.pa.us> <20200110205003.GD3195@tamriel.snowman.net> Comments: In-reply-to Stephen Frost message dated "Fri, 10 Jan 2020 15:50:03 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27617.1578696790.1@sss.pgh.pa.us> Date: Fri, 10 Jan 2020 17:53:10 -0500 Message-ID: <27618.1578696790@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Stephen Frost writes: > To be clear, I was advocating for a NEW DB-level privilege ('INSTALL' or > 'CREATE EXTENSION' if we could make that work), so that we have it be > distinct from CREATE (which, today, really means 'CREATE SCHEMA'). I still say this is wrong, or at least pointless, because it'd be a right that any DB owner could grant to himself. If we're to have any meaningful access control on extension installation, the privilege would have to be attached to some other object ... and there's no clear candidate for what. As someone noted awhile back, if we could somehow attach ACLs to potentially-installable extensions, that might be an interesting avenue to pursue. That's well beyond what I'm willing to pursue for v13, though. In the meantime, though, this idea as stated doesn't do anything except let a DB owner grant install privileges to someone else. I'm not even convinced that we want that, or that anyone needs it (I can recall zero such requests related to PLs in the past). And for sure it does not belong in a minimal implementation of this feature. regards, tom lane