On Thu, Apr 23, 2026 at 8:47 PM Jeff Davis <[email protected]> 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
