Horton
Menu

Re: Avoid orphaned objects dependencies, take 3

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Michael Paquier <michael@paquier.xyz>, Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2025-06-03T17:27:29Z
Lists: pgsql-hackers 
On Mon, Jun 2, 2025 at 10:02 AM Bertrand Drouvot
<bertranddrouvot.pg@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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid orphaned objects dependencies

  2. Don't try to record dependency on a dropped column's datatype