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 1ipdnb-0001ti-D8 for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jan 2020 19:48:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ipdnZ-0002xB-0c for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jan 2020 19:48:53 +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 1ipdnY-0002x4-Np for pgsql-hackers@lists.postgresql.org; Thu, 09 Jan 2020 19:48:52 +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 1ipdnW-00054f-1k for pgsql-hackers@lists.postgresql.org; Thu, 09 Jan 2020 19:48:52 +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 009Jme99009934; Thu, 9 Jan 2020 14:48:40 -0500 From: Tom Lane To: Robert Haas cc: Stephen Frost , Peter Eisentraut , PostgreSQL Hackers Subject: Re: Removing pg_pltemplate and creating "trustable" extensions In-reply-to: References: <20200107181727.GB3195@tamriel.snowman.net> <20200107213618.GC3195@tamriel.snowman.net> <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> Comments: In-reply-to Robert Haas message dated "Thu, 09 Jan 2020 14:06:03 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9932.1578599320.1@sss.pgh.pa.us> Date: Thu, 09 Jan 2020 14:48:40 -0500 Message-ID: <9933.1578599320@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > So, if I understand correctly, the patch you are proposing to commit > has a new system role, and if you've got that system role, then you > can install extensions. Install *trusted* extensions, correct. The patch as it stands also allows DB owners to install trusted extensions. > I thought that part of the earlier debate was > whether DB owners should also be able to install trusted extensions > even without that role, and I thought it would be cleaner if the > answer was "no," because then the superuser could decide whether to > grant that role or not in particular cases. But I'm not clear whether > you agreed with that, what Stephen thought about it, or whether that's > still what you are proposing to commit. I agree that if we dropped the proviso about DB owners, it would be a cleaner design. I included that only for backwards compatibility with the existing behavior that DB owners can install trusted PLs. If we can agree that we're willing to lose that behavior, I'd be perfectly fine with removing the special case for DB owners. However, I'm unsure whether that compatibility cost is acceptable. It's definitely likely that it would cause an upgrade headache for some installations. One idea for working around the upgrade problem would be to teach pg_dumpall to automatically issue "GRANT pg_install_trusted_extension" to each DB-owner role, when dumping from a pre-v13 database. There's room to object to that, because it would end with more privilege than before (that is, an owner of some DB could now install extensions even in DBs she doesn't own, as long as she can connect to them). So maybe it's a bad idea. But it would probably reduce the number of complaints --- and I think a lot of installations would end up making such grants anyway, because otherwise their DB owners can't do things they expect to be able to do. I should not put words into Stephen's mouth, but perhaps his concern about having some DB-level privilege here is to alleviate the problem that there's no exact equivalent to the old level of privilege that DB ownership afforded, ie you can install in your own DB but not others. It's not clear to me whether that behavior is critical to preserve. regards, tom lane