Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p36bz-0004j7-4W for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Dec 2022 02:26:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p36bw-00017k-Mo for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Dec 2022 02:26:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p36bw-00017Z-9T for pgsql-hackers@lists.postgresql.org; Thu, 08 Dec 2022 02:26:08 +0000 Received: from mail-io1-xd2b.google.com ([2607:f8b0:4864:20::d2b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p36bq-0008Kj-13 for pgsql-hackers@postgresql.org; Thu, 08 Dec 2022 02:26:07 +0000 Received: by mail-io1-xd2b.google.com with SMTP id p6so3901524iod.13 for ; Wed, 07 Dec 2022 18:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=rOijmbotfPa68WCAy6RjLeYLPXXiEju/M1sUyQs7bmw=; b=wH6diXJtsOph8CFbG/rhRPDPQz36H3lERS2hq/MvnGPi6MBakL19RvnKUC2eRhyaw1 CyagCMPCKD9eUimOXrIGRA6Mn3/yuFCc4akpChwNaVJMxgVlm+DGJQeBQyG3llB5ihqx qkaA271ZPDrJfCkuN7us4zldb34B6Z/jYWL/9P0DcppnPY/dQsbNBmkflQAYGigiDRhW cJgTHxyuvdCsMum8W9OcpAojsN9Y+B6xgv0IuWhKXbYGX5umjVrN/UPaFk9ii0nM+S5y LZrQ/fsVcVv2I+jaNaEhHvZsTfBJRcUYQPxJkw7I/fN7KhCelaLSn6+gaHidQKT/VSU8 H28g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rOijmbotfPa68WCAy6RjLeYLPXXiEju/M1sUyQs7bmw=; b=SQfW+/Y3Wml0rb4dPtR9WN5sQvnNa0Dm/y/ziXWOi147cpDOXYG49Tw3ur1d425l1q 1SOPVd/LACBUEnnwsFSp8j6kMBcB6x1Z1vj9sjI+GTaxl9lPoMeRG4tUTUOkldeZSWV5 yVULF5FRccM+OCffHS3kJf9dvqTpacW2UXnSsTxX9uNchEJenuQcINxiGVd2d0p9WY4Z 1kSbtbBfQF/AnBTwCEl3GC7eB3bbs2Pjf3JQs5wyoHizJ6B9XB0iIjFj1Ql2rTtGygUy u/bYSU+wavy21OVpNc8VFilQ2XReyMvvLabo44dyhxZ76PXipTvWi44B+MCIFC9aD+P6 R/Fw== X-Gm-Message-State: ANoB5pm/VqhUJRSbLgpiOh8Y6pCA7oMAngeLSNqi5+TgdLR3utLNy+Bw fHRBXjLuTPSXBS3C+8D14GVyag== X-Google-Smtp-Source: AA0mqf7hnOqQ1D0HkDjuea509GOwJRuRVx+TFei3GtdlaD6c1sfP85RNtN4QKEqSKdoY/FRLJ7Zlrw== X-Received: by 2002:a02:6a43:0:b0:375:4725:4b4f with SMTP id m3-20020a026a43000000b0037547254b4fmr43354179jaf.52.1670466361041; Wed, 07 Dec 2022 18:26:01 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id x3-20020a056602160300b006bba42f7822sm8612210iow.52.2022.12.07.18.26.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Dec 2022 18:26:00 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id A6885800DCC; Wed, 7 Dec 2022 20:25:59 -0600 (CST) Date: Wed, 7 Dec 2022 20:25:59 -0600 From: Justin Pryzby To: Nathan Bossart Cc: pgsql-hackers@postgresql.org Subject: Re: fix and document CLUSTER privileges Message-ID: <20221208022559.GA27893@telsasoft.com> References: <20221207223924.GA4182184@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221207223924.GA4182184@nathanxps13> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Dec 07, 2022 at 02:39:24PM -0800, Nathan Bossart wrote: > Hi hackers, > > While looking into other opportunities for per-table permissions, I noticed > a weird discrepancy in CLUSTER. When evaluating whether the current user > has permission to CLUSTER a table, we ordinarily just check for ownership. > However, the database owner is also allowed to CLUSTER all partitions that > are not shared. This was added in 3f19e17, and I didn't see any discussion > about it in the corresponding thread [0]. > > My first instinct is that we should just remove the database ownership > check, which is what I've done in the attached patch. I don't see any > strong reason to complicate matters with special > database-owner-but-not-shared checks like other commands (e.g., VACUUM). > But perhaps we should do so just for consistency's sake. Thoughts? Your patch makes it inconsistent with vacuum full, which is strange because vacuum full calls cluster. postgres=> VACUUM FULL t; VACUUM postgres=> CLUSTER t; ERROR: must be owner of table t BTW, it'd be helpful to copy the relevant parties on this kind of message, especially if there's a new thread dedicated just to this. -- Justin