Date: Tue, 24 May 2022 10:28:51 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: allow building trusted languages without the untrusted versions
Message-ID: <20220524172851.GA1191690@nathanxps13>
References: <20220520225619.GA876272@nathanxps13>
 <571753.1653092411@sss.pgh.pa.us>
 <20220523165403.GC938919@nathanxps13>
 <1290329.1653326228@sss.pgh.pa.us>
 <CA+TgmoY-Xy_ObfYVUTSamD8BmW8npaktbr65JtnkW-c1VQobVA@mail.gmail.com>
 <1333860.1653338790@sss.pgh.pa.us>
 <CA+TgmoYZKLxftaZZvj4_-zHQ27CBeUs+KvggyU3qS79-7aQEPA@mail.gmail.com>
 <1354561.1653345768@sss.pgh.pa.us>
 <CA+TgmoZ_c0j4ut87_QCFm697Qq5Z_u66VZt2PYenfZVjUT1qRA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoZ_c0j4ut87_QCFm697Qq5Z_u66VZt2PYenfZVjUT1qRA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20220524172851.GA1191690%40nathanxps13>
Precedence: bulk

On Tue, May 24, 2022 at 12:39:16PM -0400, Robert Haas wrote:
> On Mon, May 23, 2022 at 6:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [ shrug... ]  So is your point that we shouldn't bother to do anything?
>> I don't personally have a problem with leaving things where they stand
>> in this area.  However, if we're going to do something, I think at
>> minimum it should involve blocking off everything we can identify as
>> straightforward reproducible methods to get disk access.
> 
> 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.
> 
> I would argue that Stephen's proposal (that is, using predefined roles
> more) and Nathan's proposal (that is, making it possible to build only
> the trusted version of some PL) are tackling this problem are far
> superior to your idea (that is, a flag to disable all disk access)
> precisely because they are more granular. Your idea appears to
> presuppose that there is exactly one thing in this area that anybody
> wants and that we know what that thing is. I think people want a bunch
> of slightly different things and that we're probably unaware of many
> of them. Letting them pick which behaviors they want seems to me to
> make a lot of sense.

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.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com