Re: allow building trusted languages without the untrusted versions - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: allow building trusted languages without the untrusted versions
Date
Msg-id 20220524172851.GA1191690@nathanxps13
Whole thread Raw
In response to Re: allow building trusted languages without the untrusted versions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: allow building trusted languages without the untrusted versions
Re: allow building trusted languages without the untrusted versions
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Zhihong Yu
Date:
Subject: adding status for COPY progress report
Next
From: Tom Lane
Date:
Subject: Re: allow building trusted languages without the untrusted versions