Horton

Re: Possibility to disable `ALTER SYSTEM`

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: Tom Lane <tgl@sss.pgh.pa.us>, "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Magnus Hagander <magnus@hagander.net>, Robert Haas <robertmhaas@gmail.com>, Martín Marqués <martin.marques@gmail.com>, Isaac Morland <isaac.morland@gmail.com>, Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-01-31T07:43:14Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add allow_alter_system GUC.

  2. Rename COMPAT_OPTIONS_CLIENT to COMPAT_OPTIONS_OTHER.

  3. Remove support for version-0 calling conventions.

On 31.01.24 06:28, Tom Lane wrote:
>> The idea of adding a file to the data directory appeals to me.
>>
>> optional_runtime_features.conf
>> alter_system=enabled
>> copy_from_program=enabled
>> copy_to_program=disabled
> ... so, exactly what keeps an uncooperative superuser from
> overwriting that file?

The point of this feature would be to keep the honest people honest.

The first thing I did when ALTER SYSTEM came out however many years ago 
was to install Nagios checks to warn when postgresql.auto.conf exists. 
Because the thing is an attractive nuisance, especially when you want to 
do centralized configuration control.  Of course you can bypass it using 
COPY PROGRAM etc., but then you *know* that you are *bypassing* 
something.  If you just see ALTER SYSTEM, you'll think, "that is 
obviously the appropriate tool", and there is no generally accepted way 
to communicate that, in particular environment, it might not be.