Re: un-revert the MAINTAIN privilege and the pg_maintain predefined role

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