> On Mar 30, 2022, at 6:59 AM, Mark Dilger <mark.dil...@enterprisedb.com> wrote:
>
> We should review the conversation from December and January which included
> some arguments for allowing revokes of SET on USERSET from PUBLIC. I don't
> want to keep going around in circles on this.
Hmm, I guess that conversation was mostly off-list at the PGConn in December.
I made a reference to it upthread:
> On Mar 6, 2022, at 2:40 PM, Mark Dilger <mark.dil...@enterprisedb.com> wrote:
>
> Userset variables are implicitly settable by any user. There was a request,
> off-list as I recall, to make it possible to revoke the privilege to set
> variables such as "work_mem". To make that possible, but not change the
> default behavior vis-a-vis prior releases, I upgraded most userset variables
> to suset with a corresponding grant to public on the variable. Sites which
> wish to have a more restrictive policy on such variables can revoke that
> privilege from public and instead issue more restrictive grants. There were
> a few variables where such treatment didn't seem sensible, such as ones to do
> with client connections, and I left them alone. I didn't insist on a defense
> for why any particular setting needed to be revocable in order to apply this
> treatment. My assumption was that sites should be allowed to determine their
> own security policies per setting unless there is a technical difficulty for
> a given setting that would make it overly burdensome to implement.
Your proposal to just punt on supporting revocation of set on userset from
public seems fine. We could revisit that in the next development cycle if
anyone really wants to defend it. In particular, I don't see that committing
this feature without that part would create any additional backward
compatibility problems when implementing that later.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
