Re: Avoid orphaned objects dependencies, take 3

On Mon, Jun 2, 2025 at 10:02 AM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)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