Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ntYUT-00042W-Up for pgsql-hackers@arkaria.postgresql.org; Tue, 24 May 2022 17:38:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ntYUS-0001df-HB for pgsql-hackers@arkaria.postgresql.org; Tue, 24 May 2022 17:38:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ntYUS-0001WB-7F for pgsql-hackers@lists.postgresql.org; Tue, 24 May 2022 17:38:40 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ntYUM-0002Rk-OP for pgsql-hackers@postgresql.org; Tue, 24 May 2022 17:38:36 +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 24OHcW4o1679335; Tue, 24 May 2022 13:38:32 -0400 From: Tom Lane To: Nathan Bossart cc: Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: allow building trusted languages without the untrusted versions In-reply-to: <20220524172851.GA1191690@nathanxps13> References: <20220520225619.GA876272@nathanxps13> <571753.1653092411@sss.pgh.pa.us> <20220523165403.GC938919@nathanxps13> <1290329.1653326228@sss.pgh.pa.us> <1333860.1653338790@sss.pgh.pa.us> <1354561.1653345768@sss.pgh.pa.us> <20220524172851.GA1191690@nathanxps13> Comments: In-reply-to Nathan Bossart message dated "Tue, 24 May 2022 10:28:51 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1679333.1653413912.1@sss.pgh.pa.us> Date: Tue, 24 May 2022 13:38:32 -0400 Message-ID: <1679334.1653413912@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Nathan Bossart writes: > On Tue, May 24, 2022 at 12:39:16PM -0400, Robert Haas wrote: >> No, my point is that one size doesn't fit all. Bundling everything >> together that could result in a disk access is going to suck too many >> marginally-related into the same bucket. It's much better to have >> individual switches controlling individual behaviors, so that people >> can opt into or out of the behavior that they want. > Can we do both? That is, can we add retail options for untrusted > languages, generic file access functions, etc., and then also introduce a > --disable-disk-access configuration option? The latter might even just be > a combination of retail options. This would allow for more granular > configurations, but it also could help address Tom's concerns. Don't see why not. I'm a bit skeptical of Robert's position, mainly because I don't think he's offered any credible threat model that would justify disabling individual features of this sort but not all of them. However, if what it takes to have consensus is some individual knobs in addition to an "easy button", let's do it that way. regards, tom lane