Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u1Cbq-00FoaD-0b for pgsql-hackers@arkaria.postgresql.org; Sat, 05 Apr 2025 23:07:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1u1Cbo-004ay3-3r for pgsql-hackers@arkaria.postgresql.org; Sat, 05 Apr 2025 23:07:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u1Cbn-004axv-R6 for pgsql-hackers@lists.postgresql.org; Sat, 05 Apr 2025 23:07:28 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u1Cbm-003BfP-0g for pgsql-hackers@lists.postgresql.org; Sat, 05 Apr 2025 23:07:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 535N7JsZ2738791; Sat, 5 Apr 2025 19:07:19 -0400 From: Tom Lane To: Robert Haas cc: Michael Banck , Jelte Fennema-Nio , PostgreSQL Hackers Subject: Re: [PATCH] New predefined role pg_manage_extensions In-reply-to: References: <65a1524e.050a0220.49266.7670@mx.google.com> <67cb04a8.170a0220.4ffef.a81e@mx.google.com> <1021640.1741364484@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Fri, 07 Mar 2025 11:46:53 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2738789.1743894439.1@sss.pgh.pa.us> Date: Sat, 05 Apr 2025 19:07:19 -0400 Message-ID: <2738790.1743894439@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I took another look at this patch, and I still can't persuade myself that a good case has been made for it. There are too many scenarios where pg_manage_extensions would be a security problem and too few where it seems to really improve manageability. As an example, it was asserted upthread that it's not a security problem to let someone install plpython3u, because they still couldn't create any plpython3u functions unless they were superuser. Well, fine, but then what's the point of installing it? If there is someone around with enough privilege to use plpython3u, that person can install it first. I also don't buy the argument that service providers would be unwilling to set the "trusted" flag on extensions that for whatever reason they are willing to let be installed by non-superusers. This thread is full of (unsupported) assertions that those same providers are making far more invasive changes to the PG code base to achieve their desired results. Robert Haas writes: > I agree, but I also don't want the security decisions that the core > project takes to become irrelevant in practice. It seems like what's > starting to happen is that all of the cloud providers end up finding > the same issues and working around them in very similar ways and they > don't do anything in PostgreSQL itself, I guess because that would > require winning an argument on the mailing list. It would at least require showing up on the mailing list. None of the assertions made in this thread about what cloud providers are doing have been supported by a whit of evidence about that. What I'm wishing for is that some of the providers would show up here and provide specific details (preferably patches) about what they are changing and why. Then we could have an informed discussion about how to make their lives less painful in the future. Right now I think we're guessing --- I certainly am. Maybe some of the people on this thread have access to such details, but they aren't sharing. regards, tom lane