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

From Robert Haas
Subject Re: Possibility to disable `ALTER SYSTEM`
Date
Msg-id CA+TgmoZmVQ3mz-o02YOh7RiS+z3yAic_9c4=-1C7F9ufqa5B1g@mail.gmail.com
Whole thread Raw
In response to Re: Possibility to disable `ALTER SYSTEM`  (Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>)
List pgsql-hackers
On Wed, Jan 31, 2024 at 5:16 AM Gabriele Bartolini
<gabriele.bartolini@enterprisedb.com> wrote:
> I very much like the idea of a file in the data directory that also controls the copy operations.
>
> Just wanted to highlight though that in our operator we have already applied the read-only postgresql.auto.conf trick
todisable the system (see https://cloudnative-pg.io/documentation/current/postgresql_conf/#enabling-alter-system).
However,having that file read-only triggered an issue when using pg_rewind to resync a former primary, as pg_rewind
immediatelybails out when a read-only file is encountered in the PGDATA (see
https://github.com/cloudnative-pg/cloudnative-pg/issues/3698).
>
> We might keep this in mind if we go down the path of the separate file.

Yeah. It would be possible to teach pg_rewind and other utilities to
handle unreadable or unwritable files in the data directory, but I'm
not sure that's the best path forward here, and it would require some
consensus that it's the way we want to go.

Another option I thought of would be to control these sorts of things
with a command-line switch. I doubt whether that does anything really
fundamental from a security point of view, but it removes the control
of the toggles from anything in the data directory while still leaving
it within the server administrator's remit.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Eli Schwartz
Date:
Subject: Re: make dist using git archive
Next
From: Matthias van de Meent
Date:
Subject: Re: Reducing output size of nodeToString