Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: 
 <CAGB+Vh5pVFAqw8YzeXy4xxmEt_4Hq_8pEUHdCQvv3mCjvC-S-w@mail.gmail.com>
Date: Wed, 15 Dec 2021 10:18:05 -0800
Cc: Andrew Dunstan <andrew@dunslane.net>,
 Robert Haas <robertmhaas@gmail.com>,
 Jeff Davis <pgsql@j-davis.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Tom Lane <tgl@sss.pgh.pa.us>,
 Joe Conway <joe@crunchydata.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA57D4A2-B17F-46ED-92A6-22FF25FEA795@enterprisedb.com>
References: <3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com>
 <CA+TgmobaKUYZhfXs-7kHjsmDmkcttH7-r9E2BJXUHtv9mkUUcw@mail.gmail.com>
 <AAE7FBCE-7C7D-4E92-A57F-D4496B306DDF@enterprisedb.com>
 <CA+TgmobUt_tSF-9tz-eRvWzT1pbe_ssvxfnPniGGEgLzems40Q@mail.gmail.com>
 <9DB8DABC-0E1E-4AB0-BB11-9BC48E4C71BE@enterprisedb.com>
 <df224438-bcb5-5543-8ff6-841ce91053fb@dunslane.net>
 <BA6C2DC4-A169-4239-B7E2-B4F73EA908E3@enterprisedb.com>
 <A9802425-8920-4814-9BE1-5C7250E2C386@enterprisedb.com>
 <E6D03A76-4D79-43BE-B896-4571E9FE323B@enterprisedb.com>
 <CAGB+Vh4_UJsYHCWborm-y4CFt8gVvY_KbcNrpWcpXAk-GcwOtA@mail.gmail.com>
 <2D6C1081-DB7D-4260-8987-5B4912E95917@enterprisedb.com>
 <CAGB+Vh5pVFAqw8YzeXy4xxmEt_4Hq_8pEUHdCQvv3mCjvC-S-w@mail.gmail.com>
To: Joshua Brindle <joshua.brindle@crunchydata.com>
Archived-At: 
 <https://www.postgresql.org/message-id/FA57D4A2-B17F-46ED-92A6-22FF25FEA795%40enterprisedb.com>
Precedence: bulk


> On Dec 15, 2021, at 10:02 AM, Joshua Brindle =
<joshua.brindle@crunchydata.com> wrote:
>=20
> Ah, I was actually requesting a hook where the acl check was done for
> setting a GUC, such that we could deny setting them in a hook,
> something that would be useful for the set_user extension
> (github.com/pgaudit/set_user)

Hmm, this seems orthogonal to the patch under discussion.  This patch =
only adds a pg_setting_acl_aclcheck in ExecSetVariableStmt() for =
settings which have been explicitly granted, otherwise it works the =
traditional way (checking whether the setting is suset/userset).  I =
don't think you'd get MAC support without finding a way to fire the hook =
for all settings, regardless of their presence in the new pg_setting_acl =
table.  That is hard, because InvokeObjectPostAlterHook expects the =
classId (SettingAclRelationId) and the objectId (pg_setting_acl.oid), =
but you don't have those for many (most?) settings.  As discussed =
upthread, we *do not* want to force an entry into the table for all =
settings, only for ones that have been explicitly granted.

Do you agree?  I'm happy to support MAC in this patch if can explain a =
simple way of doing so.

> but having a hook for grant/revoke is
> also helpful.

Yes, I see no reason to rip this out.

=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company