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

> On Mar 6, 2022, at 2:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 1. If we need to change these two contrib modules, doesn't that imply
> a lot of changes forced on external modules as well?  What are the
> security implications if somebody doesn't make such a change?
>
> 2. It looks to me like if someone installs the updated postgres_fdw.so,
> but doesn't run ALTER EXTENSION UPDATE, they are going to be left with a
> rather broken extension.  This seems not good either, especially if it's
> multiplied by a boatload of third-party extensions requiring updates.
>
> So I think some more thought is needed to see if we can't avoid
> the need to touch extension modules in this patch.  Or at least
> avoid the need for synchronized C-level and SQL-level updates,
> because that is going to create a lot of pain for end users.
>
> I'm also fairly distressed by the number of changes in guc.c,
> mainly because I fear that that means that pending patches that
> add GUC variables will be subtly incorrect/insecure if they're not
> updated to account for this.  Frankly, I also reject the apparent
> position that we need to support forbidding users from touching
> many of these GUCs.  Or, if that's our position, why are there
> per-GUC changes at all, rather than just redefining what the
> context values mean?  (That is, why not redefine USERSET and
> SUSET as simply indicating the default ACL to be applied if there's
> no entry in the catalog.)

To my knowledge, there is no mechanism to revoke an implicit privilege.  You can revoke a privilege explicitly listed
inan aclitem[], but only if the privilege is being tracked that way. 

Userset variables are implicitly settable by any user.  There was a request, off-list as I recall, to make it possible
torevoke the privilege to set variables such as "work_mem".  To make that possible, but not change the default behavior
vis-a-visprior 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
andinstead issue more restrictive grants.  There were a few variables where such treatment didn't seem sensible, such
asones 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. 

It seemed more complete to do the same thing for contrib modules, so I did.

If a third-party module doesn't do the equivalent operation, they would simply continue with their userset variables
workingas before.  I don't see a specific security concern with that, though I'd be happy to consider arguments to the
contrary.

I believe there are also some issues with this patch relating to pg_dump/pg_restore and to pg_upgrade, which EDB is
workingto address.  We intend to repost something soon. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company