Re: Granting SET and ALTER SYSTE privileges for GUCs

On Wed, Dec 15, 2021 at 10:56 AM Mark Dilger
<mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>
>
>
> > On Dec 14, 2021, at 2:26 PM, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com> wrote:
> >
> > currently there is a failure in check-world (not sure if it's known):
>
> That one is definitely my fault. 'en_US.UTF-8' exists on my platform, so I hadn't noticed. I've changed it to use 'C', which should be portable.
>
> > One thing that seems like an omission to me is the absence of a
> > InvokeObjectPostAlterHook in pg_setting_acl_aclcheck or
> > pg_setting_acl_aclmask so that MAC extensions can also block this,
> > InvokeObjectPostCreateHook is already in the create path so a
> > PostAlter hook seems appropriate.
>
> Good catch, but that seems like a strange place to put a PostAlterHook, so I added it to ExecGrant_Setting for v6, instead. This seems more consistent with the hook in SetDefaultACL.

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) but having a hook for grant/revoke is
also helpful.

> (If you are really trying to do Managed Access Control (MAC), wouldn't that be a separate patch which adds security hooks into all *_aclcheck functions?)

MAC is mandatory access controls, so something that can be layered on
top of DAC and can only be enforced even on object owners and
superuser. sepgsql is a MAC extension, for example. It uses the object
access hooks to enforce SELinux policy on PG objects.