public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: Ted Yu <[email protected]>
Cc: Pavel Luzanov <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: [email protected]
Subject: Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX
Date: Wed, 14 Jun 2023 08:16:15 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <20230613211246.GA219055@nathanxps13>
References: <CALte62zW+s+V3fDUxP2ZYk2f=DZsyZO-Aa_bbiA39=wrz=UHuQ@mail.gmail.com>
<20221218233018.GA1476904@nathanxps13>
<20230103234549.GA289060@nathanxps13>
<20230109225157.GA1288965@nathanxps13>
<[email protected]>
<20230113203334.GA2206335@nathanxps13>
<[email protected]>
<20230113225626.GA2380176@nathanxps13>
<20230113231339.GA2422750@nathanxps13>
<20230613211246.GA219055@nathanxps13>
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
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (18+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox