On Tue, May 24, 2022 at 12:39:16PM -0400, Robert Haas wrote: > On Mon, May 23, 2022 at 6:42 PM Tom Lane <t...@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
