Re: Granting SET and ALTER SYSTE privileges for GUCs - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: Granting SET and ALTER SYSTE privileges for GUCs
Date
Msg-id FA57D4A2-B17F-46ED-92A6-22FF25FEA795@enterprisedb.com
Whole thread Raw
In response to Re: Granting SET and ALTER SYSTE privileges for GUCs  (Joshua Brindle <joshua.brindle@crunchydata.com>)
Responses Re: Granting SET and ALTER SYSTE privileges for GUCs
List pgsql-hackers

> On Dec 15, 2021, at 10:02 AM, Joshua Brindle <joshua.brindle@crunchydata.com> wrote:
>
> 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
whetherthe setting is suset/userset).  I don't think you'd get MAC support without finding a way to fire the hook for
allsettings, regardless of their presence in the new pg_setting_acl table.  That is hard, because
InvokeObjectPostAlterHookexpects the classId (SettingAclRelationId) and the objectId (pg_setting_acl.oid), but you
don'thave those for many (most?) settings.  As discussed upthread, we *do not* want to force an entry into the table
forall 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.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Shay Rojansky
Date:
Subject: Re: Privilege required for IF EXISTS event if the object already exists
Next
From: "Bossart, Nathan"
Date:
Subject: Re: archive modules