On Wed, Dec 15, 2021 at 10:56 AM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > > > > > On Dec 14, 2021, at 2:26 PM, Joshua Brindle > > <joshua.brin...@crunchydata.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.
