Re: Possibility to disable `ALTER SYSTEM` - Mailing list pgsql-hackers

From Isaac Morland
Subject Re: Possibility to disable `ALTER SYSTEM`
Date
Msg-id CAMsGm5f_uCvLMBp8N=J-kFxgGDzVVVTutSProRVwhHNMMpgaYw@mail.gmail.com
Whole thread Raw
In response to Re: Possibility to disable `ALTER SYSTEM`  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Possibility to disable `ALTER SYSTEM`
List pgsql-hackers
On Mon, 11 Sept 2023 at 11:11, Magnus Hagander <magnus@hagander.net> wrote:

> I'm actually going to put a strong +1 to Gabriele's proposal. It's an
> undeniable problem (I'm only seeing arguments regarding other ways the
> system would be insecure), and there might be real use cases for users
> outside kubernetes for having this feature and using it (meaning
> disabling the use of ALTER SYSTEM).

If enough people are in favor of it *given the known issues with it*,
I can drop my objection to a "meh, but I still don't think it's a good
idea".

But to do that, there would need to be a very in-your-face warning in
the documentation about it like "note that this only disables the
ALTER SYSTEM command. It does not prevent a superuser from changing
the configuration remotely using other means".

For example, in the very simplest, wth the POC patch out there now, I
can still run:
[…]

Maybe in addition to making "ALTER SYSTEM" throw an error, the feature that disables it should also disable reading postgresql.auto.conf? Maybe even delete it and make it an error if it is present on startup (maybe even warn if it shows up while the DB is running?).

Interesting corner case: What happens if I do "ALTER SYSTEM SET alter_system_disabled = true"?

Counterpoint: maybe the idea is to disable ALTER SYSTEM but still use postgresql.auto.conf, maintained by an external program, to control the instance's behaviour.

pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: pg_rewind with cascade standby doesn't work well
Next
From: Pavel Stehule
Date:
Subject: Re: How to add built-in func?