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 1nQzoW-0001Iz-H4 for pgsql-hackers@arkaria.postgresql.org; Sun, 06 Mar 2022 22:57:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nQzoU-0005ur-OF for pgsql-hackers@arkaria.postgresql.org; Sun, 06 Mar 2022 22:57:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nQzoU-0005uh-Ez for pgsql-hackers@lists.postgresql.org; Sun, 06 Mar 2022 22:57:18 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nQzoT-0002RZ-0K for pgsql-hackers@postgresql.org; Sun, 06 Mar 2022 22:57:18 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 226MvAFG083815; Sun, 6 Mar 2022 17:57:10 -0500 From: Tom Lane To: Mark Dilger cc: Joshua Brindle , Andrew Dunstan , Robert Haas , Jeff Davis , PostgreSQL-development , Joe Conway Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs In-reply-to: References: <3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com> <9DB8DABC-0E1E-4AB0-BB11-9BC48E4C71BE@enterprisedb.com> <2D6C1081-DB7D-4260-8987-5B4912E95917@enterprisedb.com> <1A6DA47B-2D5F-427E-AD72-1D8BD23BF94C@enterprisedb.com> <79685.1646604824@sss.pgh.pa.us> Comments: In-reply-to Mark Dilger message dated "Sun, 06 Mar 2022 14:40:50 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83813.1646607430.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 06 Mar 2022 17:57:10 -0500 Message-ID: <83814.1646607430@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Mark Dilger writes: >> On Mar 6, 2022, at 2:13 PM, Tom Lane wrote: >> ... Or, if that's our position, why are there >> per-GUC changes at all, rather than just redefining what the >> context values mean? (That is, why not redefine USERSET and >> SUSET as simply indicating the default ACL to be applied if there's >> no entry in the catalog.) > To my knowledge, there is no mechanism to revoke an implicit privilege. = You can revoke a privilege explicitly listed in an aclitem[], but only if= the privilege is being tracked that way. So? What I'm suggesting is along the lines of (1) pg_setting_acl starts out empty, or at least mostly empty (maybe there are a few GUCs that need custom values). (2) If there's a pg_setting_acl entry for a GUC that's to be set, we apply it: either it grants the desired permission or it doesn't. (3) If there's no entry, then for a USERSET GUC we assume that the entry would be like "=3Ds/postgres", while for any other context value we assume the ACL grants nothing. I don't think this is materially different from what we do with permissions on (say) functions. If you want to revoke the public SET privilege on some USERSET variable, you instantiate the default and then revoke. You end up with an empty ACL stored in pg_setting_acl, and voila. It'd likely be necessary to refuse to record a grant/revoke on an unknown GUC, since if we don't know the GUC then we can't know what the relevant default ACL ought to be. But I bet your existing patch has some dubious behavior in that case too. regards, tom lane