Re: un-revert the MAINTAIN privilege and the pg_maintain predefined role - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: un-revert the MAINTAIN privilege and the pg_maintain predefined role
Date
Msg-id 20240312210541.GA2400644@nathanxps13
Whole thread Raw
In response to Re: un-revert the MAINTAIN privilege and the pg_maintain predefined role  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: un-revert the MAINTAIN privilege and the pg_maintain predefined role
List pgsql-hackers
On Thu, Mar 07, 2024 at 10:50:00AM -0600, Nathan Bossart wrote:
> Given all of this code was previously reviewed and committed, I am planning
> to forge ahead and commit this early next week, provided no objections or
> additional feedback materialize.

Jeff Davis and I spent some additional time looking at this patch.  There
are existing inconsistencies among the privilege checks for the various
maintenance commands, and the MAINTAIN privilege just builds on the status
quo, with one exception.  In the v1 patch, I proposed skipping privilege
checks when VACUUM recurses to TOAST tables, which means that a user may be
able to process a TOAST table for which they've concurrent lost privileges
on the main relation (since each table is vacuumed in a separate
transaction).  It's easy enough to resolve this inconsistency by sending
down the parent OID when recursing to a TOAST table and using that for the
privilege checks.  AFAICT this avoids any kind of cache lookup hazards
because we hold a session lock on the main relation in this case.  I've
done this in the attached v2.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: On disable_cost
Next
From: Tom Lane
Date:
Subject: Re: On disable_cost