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

From Joshua Brindle
Subject Re: Granting SET and ALTER SYSTE privileges for GUCs
Date
Msg-id CAGB+Vh65R5vKC4rEt7r2_pK3kMZd-VY0n99RJwcP8Bic7xvOxQ@mail.gmail.com
Whole thread Raw
In response to Re: Granting SET and ALTER SYSTE privileges for GUCs  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers
On Thu, Dec 16, 2021 at 12:53 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
>
>
>
> > On Dec 16, 2021, at 7:43 AM, Joshua Brindle <joshua.brindle@crunchydata.com> wrote:
> >
> > Ah, I understand now. Would it be possible to pass the
> > SettingAclRelationId if it exists or InvalidOid if not?
>
> SettingAclRelationId is always defined, so we can always pass that value.  But the settingId itself may sometimes be
InvalidOid.

Yes, that is what I meant.

> > That way if a
> > MAC implementation cares about a particular GUC it'll ensure it's in
> > pg_setting_acl.
>
> A much cleaner solution would be to create new ObjectAccessTypes with a corresponding new Invoke macro and Run
function. Those could take setting names, not Oids, and include additional information about whether the operation is
SET,RESET or ALTER SYSTEM, what the new value is (if any), what kind of setting it is (bool, int, ...), etc.  I don't
thinksuch a patch would even be all that hard to write. 
>
> What do you think?

Personally, I would be happy with that, but since it's a whole new
hooking method I suspect it'll be an uphill battle. That definitely
seems like another patchset though, if you do submit this I will test
and review.

Thank you.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Apple's ranlib warns about protocol_openssl.c
Next
From: Jacob Champion
Date:
Subject: Re: [PATCH] Accept IP addresses in server certificate SANs