On Mon, Jun 1, 2026 at 11:47 AM Jacob Champion <[email protected]> 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
