Re: allow building trusted languages without the untrusted versions

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(at)sss(dot)pgh(dot)pa(dot)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