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
signature.asc
Description: PGP signature