Hi, On Thu, Jun 18, 2026 at 07:13:38PM -0700, Jeff Davis wrote: > On Thu, 2026-06-18 at 16:21 -0700, Jeff Davis wrote: > > IIUC, we cannot have false positives (tracking ACL checks that > > wouldn't > > have caused an abort) nor can we have false negatives (missing an ACL > > check that could cause an abort). > > Idea: what if we check for changes in ACLs on the object, rather than > whether it passes the check or not? > > Then, if track an ACL check that wouldn't actually cause a failure, > then it still might be acceptable to throw an error if the ACL changes. > Still some details to sort out, so this is just an idea.
Yeah, I think I do prefer this idea. As you say, that could cause an error even if the ACL change does not REVOKE anything on this object (say the ACL change is a GRANT), but that should be rare in practice and probably much simpler to reason about that way. But I don't think tracking ACL changes would be enough though. I think we would also need to track ROLE changes. So what about? - Save a copy of the object's ACL and compare at recheck time: If not the same, then error out. - Save the ROLE membership and compare at recheck time. If not the same, then error out. That way we cover both parts: the object's ACL and the ROLE membership. That's just a high level idea, I can move forward and try to implement it. Thoughts? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
