Thread

Re: sandboxing untrusted code

Robert Haas <robertmhaas@gmail.com> — 2026-05-28T18:48:32Z

On Thu, Apr 23, 2026 at 8:47 PM Jeff Davis <pgsql@j-davis.com> wrote:
> 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.

Agreed. There are a bunch of contexts where we allow calling DML or
DDL that can do literally anything where that seems crazy. Like,
imagine a type default or an index predicate running ALTER USER ...
SUPERUSER. That is a supported scenario, but it's nuts: there's no
legitimate reason to allow it. We could certainly design a bespoke
mechanism to prevent that specific kind of problem and I do not think
that would be a terrible idea. However, if we implement a general
provenances solution like what I propose in the other email that I
just sent, it takes care of this stuff too for very little additional
cost. Extending the provenance chain down through these types of calls
is not especially difficult -- the difficult cases are actually in the
rewriter and the planner more than anything else, from what I have
seen so far. Once you have the provenance chain here, you can either
decide to block it only if it violates some general policy like "block
attempts by untrusted users to induce DDL execution" or you can add a
more specific rule like "block DDL from index expressions, index
predicates, type defaults, etc. categorically".

Or, again, if we decide against the provenances mechanism, then we can
still choose to enforce rules like this via some other route. However,
I think that approach cuts off much less of the attack surface area.

-- 
Robert Haas
EDB: http://www.enterprisedb.com