Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX

On Tue, Jun 13, 2023 at 02:12:46PM -0700, Nathan Bossart wrote:
> I've been reviewing ff9618e lately, and I'm wondering whether it has the
> same problem that 19de0ab solved. Specifically, ff9618e introduces
> has_partition_ancestor_privs(), which is used to check whether a user has
> MAINTAIN on any partition ancestors. This involves syscache lookups, and
> presently this function does not take any relation locks. I did spend some
> time trying to induce cache lookup errors, but I didn't have any luck.
> However, unless this can be made safe without too much trouble, I think I'm
> inclined to partially revert ff9618e, leaving the TOAST-related parts
> intact.

Hmm. get_rel_relispartition() and pg_class_aclcheck() are rather
reliable when it comes to that as far as it goes. Still
get_partition_ancestors() is your problem, isn't it? Indeed, it seems
like a bad idea to do partition tree lookups without at least an
AccessShareLock as you may finish with a list that makes
pg_class_aclcheck() complain on a missing relation. The race is
pretty narrow, but a stop point in get_partition_ancestors() with some
partition tree manipulation should be enough to make operations like a
schema-wide REINDEX less transparent with missing relations at least.

has_partition_ancestor_privs() is used in
RangeVarCallbackMaintainsTable(), on top of that. As written, it
encourages incorrect use patterns.

> By reverting the partition-related parts of ff9618e, users would need to
> have MAINTAIN on the partition itself to perform the maintenance command.
> MAINTAIN on the partitioned table would no longer be sufficient. This is
> more like how things work on supported versions today. Privileges are
> checked for each partition, so a command that flows down to all partitions
> might refuse to process a partition (e.g., if the current user doesn't own
> the partition).
>
> In the future, perhaps we could reevaluate adding these partition ancestor
> privilege checks, but I'd rather leave it out for now instead of
> introducing behavior in v16 that is potentially buggy and difficult to
> remove post-GA.

While on it, this buzzes me:
static bool
-vacuum_rel(Oid relid, RangeVar *relation, VacuumParams *params)
+vacuum_rel(Oid relid, RangeVar *relation, VacuumParams *params, bool skip_privs)

VacuumParams has been originally introduced to avoid extending
vacuum_rel() with a bunch of arguments, no?

So, yes, agreed about the removal of has_partition_ancestor_privs().
I am adding an open item assigned to you and Jeff.
--
Michael