Re: vacuumdb: permission denied for schema "pg_temp_7"

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Christophe Pettus <xof(at)thebuild(dot)com>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, vaibhave postgres <postgresvaibhave(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, vsekar(at)microsoft(dot)com
Subject: Re: vacuumdb: permission denied for schema "pg_temp_7"
Date: 2024-09-24 14:20:43
Message-ID: 00d98a9f-bec1-4cd0-b59e-1043ae04c8bc@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2024/09/24 10:08, Michael Paquier wrote:
> On Mon, Sep 23, 2024 at 11:48:21AM -0700, Christophe Pettus wrote:
>> I'm happy to pick it up iff the current patch submitter doesn't want
>> to continue with it.
>
> Somewhat missed this thread, thanks for the latest activity.
>
> If we apply a restriction on the temporary persistence, then we know
> that vacuumdb will always have a WHERE clause so we can simplify the
> code and remove the business with has_where like in the attached.

LGTM.

> 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.

Sorry if I misunderstood your point.

> The REINDEX one is really something that we need to care about? One
> needs database ownership for a database-level REINDEX, or schema-level
> ownership for the schema-level one. Stricter restrictions apply
> compared to vacuum_rel().

Is ownership really necessary in these cases? A similar issue can easily
happen with reindexdb as follows, so I think that should be fixed as well.

=# CREATE ROLE admin WITH LOGIN;
=# GRANT pg_maintain TO admin;
=# CREATE TEMP TABLE tt (i int primary key);
=# \! bin/reindexdb -U admin -j 2 postgres
reindexdb: error: query failed: ERROR: permission denied for schema pg_temp_0
LINE 4: AND c.oid OPERATOR(pg_catalog.=) 'pg_temp_0.tt'::pg_catalo...
^
reindexdb: detail: Query was: SELECT c.relname, ns.nspname
FROM pg_catalog.pg_class c, pg_catalog.pg_namespace ns
WHERE c.relnamespace OPERATOR(pg_catalog.=) ns.oid
AND c.oid OPERATOR(pg_catalog.=) 'pg_temp_0.tt'::pg_catalog.regclass;

We should probably add a condition like "relpersistence != CppAsString2(RELPERSISTENCE_TEMP)"
to the queries in get_parallel_object_list().

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Nathan Bossart 2024-09-24 14:26:21 Re: vacuumdb: permission denied for schema "pg_temp_7"
Previous Message Tender Wang 2024-09-24 13:10:48 Re: BUG #18628: Race condition during attach/detach partition breaks constraints of partition having foreign key