Re: Granting SET and ALTER SYSTE privileges for GUCs

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

regards, tom lane