Re: vacuumdb: permission denied for schema "pg_temp_7" - Mailing list pgsql-bugs

From Nathan Bossart
Subject Re: vacuumdb: permission denied for schema "pg_temp_7"
Date
Msg-id ZvLMDXv1XrxuJfT3@nathan
Whole thread Raw
In response to Re: vacuumdb: permission denied for schema "pg_temp_7"  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: vacuumdb: permission denied for schema "pg_temp_7"
List pgsql-bugs
On Tue, Sep 24, 2024 at 11:20:43PM +0900, Fujii Masao wrote:
> On 2024/09/24 10:08, Michael Paquier wrote:
>> About the permission restrictions depending on the objects listed, the
>> filtering query uses currently a list of VALUES in a CTE.  Perhaps it
>> would be more elegant to switch that to a SELECT with some
>> has_schema_privilege() for the cases where OBJFILTER_SCHEMA is
>> used?
>> 
>> There permission checks with USAGE and MAINTAIN are broader, so I'd
>> choose to add a skip on the temp persistence first and backpatch it
>> down to 12 as there is also a performance argument.  Then tackle the
>> rest by reworking the VALUES part in the CTE.
> 
> Are you suggesting that any objects a user lacks sufficient privileges for
> should be silently excluded from vacuuming? This could make vacuumdb appear
> successful because no errors occur, but some tables the user intended to
> vacuum might be skipped without notice. That seems more problematic to me.

Yeah, this is what I mentioned upthread [0].  If the user doesn't specify
anything in --table or --schema, then it's probably fine to silently skip
objects for which they lack privileges.  But if they do explicitly specify
a table or schema that they cannot vacuum, then IMHO it'd be better to
fail.

[0] https://postgr.es/m/Zu3iMzfiGBTbg3iy%40nathan

-- 
nathan



pgsql-bugs by date:

Previous
From: Tender Wang
Date:
Subject: Re: BUG #18628: Race condition during attach/detach partition breaks constraints of partition having foreign key
Next
From: Nathan Bossart
Date:
Subject: Re: vacuumdb: permission denied for schema "pg_temp_7"