> On Mar 30, 2022, at 6:59 AM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>
> We should review the conversation from December and January which included some arguments for allowing revokes of SET
onUSERSET 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.dilger@enterprisedb.com> wrote:
>
> Userset variables are implicitly settable by any user. There was a request, off-list as I recall, to make it
possibleto revoke the privilege to set variables such as "work_mem". To make that possible, but not change the default
behaviorvis-a-vis prior releases, I upgraded most userset variables to suset with a corresponding grant to public on
thevariable. Sites which wish to have a more restrictive policy on such variables can revoke that privilege from
publicand instead issue more restrictive grants. There were a few variables where such treatment didn't seem sensible,
suchas ones to do with client connections, and I left them alone. I didn't insist on a defense for why any particular
settingneeded to be revocable in order to apply this treatment. My assumption was that sites should be allowed to
determinetheir own security policies per setting unless there is a technical difficulty for a given setting that would
makeit 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
thenext development cycle if anyone really wants to defend it. In particular, I don't see that committing this feature
withoutthat part would create any additional backward compatibility problems when implementing that later.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
