From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: fix and document CLUSTER privileges |
Date: | 2022-12-08 21:08:40 |
Message-ID: | CA+TgmoaWhAjTP3a9xjA2P=xkF-RV9UOYT11JVWgQq5A8AB9ZrA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 8, 2022 at 1:13 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> On Thu, Dec 08, 2022 at 07:20:28AM -0500, Andrew Dunstan wrote:
> > We should probably talk about what the privileges should be, though. I
> > think there's a case to be made that CLUSTER should be governed by the
> > VACUUM privileges, given how VACUUM FULL is now implemented.
>
> Currently, CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX (minus REINDEX
> SCHEMA|DATABASE|SYSTEM) require ownership of the relation or superuser. In
> fact, all three use the same RangeVarCallbackOwnsTable() callback function.
> My current thinking is that this is good enough. I don't sense any strong
> demand for allowing database owners to run these commands on all non-shared
> relations, and there's ongoing work to break out the privileges to GRANT
> and predefined roles.
+1.
I don't see why being the database owner should give you the right to
run a random subset of commands on any table in the database. Tables
have their own system for access privileges; we should use that, or
extend it as required.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2022-12-08 21:24:00 | Re: Aggregate node doesn't include cost for sorting |
Previous Message | Robert Haas | 2022-12-08 21:00:10 | Re: Error-safe user functions |