Re: sandboxing untrusted code

On Thu, 2023-08-31 at 11:25 -0400, Robert Haas wrote:
> And that brings me to another point, which is that we might think of
> sandboxing some operations, either by default or unconditionally, for
> reasons other than trust or the lack of it. There's a lot of things
> that you COULD do in an index expression that you really SHOULD NOT
> do. As mentioned, even reading a table is pretty sketchy, but should
> a
> function called from an index expression ever be allowed to execute
> DDL? Is it reasonable if such a function wants to execute CREATE
> TABLE? Even a temporary table is dubious, and a non-temporary table
> is
> really dubious. What if such a function wants to ALTER ROLE ...
> SUPERUSER? I think that's bonkers and should almost certainly be
> categorically denied. Probably someone is trying to hack something,
> and even if they aren't, it's still nuts. So I would argue that in a
> context like an index expression, some amount of sandboxing -- not
> necessarily corresponding to either of the levels described above --
> is probably a good idea, not based on the relationship between
> whatever users are involved, but based rather on the context. There's
> room for a lot of bikeshedding here and I don't think this kind of
> thing is necessarily the top priority, but I think it's worth
> thinking
> about.

"sandboxing... based rather on context" is worth discussing further, in
my opinion.

Imagine two criteria: (a) how hard is it to avoid accidentally invoking
the expression; and (b) how restrictive a sandbox around the expression
might be before it breaks reasonable use cases.

For instance, index expressions are pretty hard to avoid invoking
accidentally, but a sandbox could be quite restrictive before it really
started breaking index expressions. In contrast, we can't be too
restrictive when evaluating functions-in-views because it would break
too many things, but whether they get executed accidentally can be
controlled with restrict_nonsystem_relation_kind.

Regards,
Jeff Davis