Re: Granting SET and ALTER SYSTE privileges for GUCs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <joe(at)crunchydata(dot)com>
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Date: 2022-03-06 22:13:44
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
> [ v8-0001-Allow-GRANT-of-SET-and-ALTER-SYSTEM-SET-for-gucs.patch ]

I noticed that this is failing in the cfbot as a side-effect of my
cc50080a8, so here's a rebase (basically it just removes the no-
longer-necessary sanity_check.out hunk).

I haven't reviewed this particularly, or read the thread, but I'm
pretty disturbed by the contrib/ changes that it proposes.

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,
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.)

regards, tom lane

Attachment Content-Type Size
v9-0001-Allow-GRANT-of-SET-and-ALTER-SYSTEM-SET-for-gucs.patch text/x-diff 203.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2022-03-06 22:31:33 Comment typo in CheckCmdReplicaIdentity
Previous Message Zhihong Yu 2022-03-06 20:37:00 Re: timestamp for query in pg_stat_statements