On Mon, Jun 2, 2025 at 10:02 AM Bertrand Drouvot <bertranddrouvot...@gmail.com> wrote: > So, we currently have 2 patterns: > > P1: permission checks on a referenced object is done before we call > recordMultipleDependencies() > P2: permission checks on a referenced object is done after we call > recordMultipleDependencies() > > So, if we add locking in recordMultipleDependencies() then I think that P2 is > worst > than P1 (there is still the risk that the permissions changed by the time > we reach recordMultipleDependencies() though).
Hmm. I don't think I agree. If I understand correctly, P2 only permits users to take a lock on an object they shouldn't be able to touch, permitting them to temporarily interfere with access to it. P1 permits users to potentially perform a permanent catalog modification that should have been blocked by the permissions system. To my knowledge, we've never formally classified the former type of problem as a security vulnerability, although maybe there's an argument that it is one. We've filed CVEs for problems of the latter sort. -- Robert Haas EDB: http://www.enterprisedb.com
