Re: sandboxing untrusted code

On Mon, Jun 1, 2026 at 11:47 AM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> I really like this idea in the abstract. No idea if I'll like the
> code, but I think tracking the causes of all the parts of an operation
> is a really good way forward.

Cool. I don't know if you'll like the code either. It's mostly
mechanical but there's a lot of it already and there will be more. The
ratio of interesting code to plumbing is exceptionally low.

> I think it'd be nice to develop a definition of "fully-trusted
> infrastructure" so we can reason about and expand upon it.

What I meant was: if you configure the system sufficiently badly, it
will definitely be insecure. The definition of "sufficiently badly" is
something we need to negotiate and agree on, but FOR EXAMPLE if you
allow anyone on the Internet to log in as superuser whenever they
want, you can't reasonably expect the system to be secure in any
meaningful sense. In the same way, we might deem type output functions
and operator classes/families to be things that must be configured in
a secure way in order for the provenances system to actually work --
and we would then document that requirement. Or we might say that's
not a requirement and make the system handle them the same as it does
other things, at the cost of more code. TBD.

> For example, you and I have discussed the concept of "purity" (in the
> mathematical sense), which might be a more powerful concept than
> LEAKPROOF or IMMUTABLE while still coexisting nicely with them. A DBA
> might reasonably decide that, for some sufficiently strong definition
> of pure, it doesn't matter what the provenance is.

I think that's absolutely correct. If Alice objects to Bob inducing
her to call a pure function, e.g. pg_catalog.int4pl(int4, int4) then
she probably just shouldn't ever interact with an object owned by Bob.
That's a reasonable decision on Alice's part, but if that's the choice
she wants to make, she doesn't actually need this system all that
badly. She can just avoid Bob's objects like the plague. The situation
in which she needs this system is if she does what to interact with
objects owned by Bob and is willing to call innocuous functions like
int4pl at his request, but is not willing to call more dangerous
functions at his request. That is not to say that an "absolutely zero
trust" mode couldn't be useful, e.g. for debugging, or to guard
against accidental references to Bob-owned objects. But for the most
part I think it will be more useful to avoid blocking calls to pure
functions. One of the worst things for a security system to do is be
so annoying that users turn it off, and blocking stuff that a human
will immediately identify as harmless is a quick route to that goal.

> All this to say: I like it.

Thanks for taking the time to write back.

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