Mark Dilger <mark.dilger@enterprisedb.com> writes:
> On Mar 6, 2022, at 2:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I don't think this is materially different from what we do with
>> permissions on (say) functions. If you want to revoke the public
>> SET privilege on some USERSET variable, you instantiate the default
>> and then revoke. You end up with an empty ACL stored in pg_setting_acl,
>> and voila.
> I assume you mean the implementation of REVOKE does this, not that the user needs to do both a grant and a revoke.
Right. Again, look at what happens when you create a function and
then revoke its default PUBLIC EXECUTE permission.
>> It'd likely be necessary to refuse to record a grant/revoke on
>> an unknown GUC, since if we don't know the GUC then we can't know
>> what the relevant default ACL ought to be. But I bet your existing
>> patch has some dubious behavior in that case too.
> The existing patch allows grants on unknown gucs, because it can't know what guc an upgrade script will introduce,
andthe grant statement may need to execute before the guc exists.
Yeah, that's the problematic case. It might mostly work to assume that
an unknown GUC has an empty default ACL. This could fail to retain the
default PUBLIC SET permission if it later turns out the GUC is USERSET
... but I suspect in most cases anybody who's messing with the permissions
would've started out by revoking that anyway. We could make this
definitely work in pg_dump if we teach pg_dump to explicitly grant or
revoke the PUBLIC SET permission anytime it's emitting anything for
a GUC, even if it thinks that would be the default state anyway.
Extension scripts that want to modify permissions for their GUCs
could follow that same principle to be sure.
regards, tom lane