Re: Possibility to disable `ALTER SYSTEM`

From: Michael Banck <mbanck(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Bruce Momjian <bruce(at)momjian(dot)us>, Joel Jacobson <joel(at)compiler(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Gabriele Bartolini <gabriele(dot)bartolini(at)enterprisedb(dot)com>, Magnus Hagander <magnus(dot)hagander(at)redpill-linpro(dot)com>, Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>
Subject: Re: Possibility to disable `ALTER SYSTEM`
Date: 2024-03-20 09:30:54
Message-ID: 65faaccf.5d0a0220.b1779.5914@mx.google.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Mar 19, 2024 at 10:51:50AM -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> > Perhaps we could make that even better with a GUC though. I propose a
> > GUC called 'configuration_managed_externally = true / false". If you set
> > it to true, we prevent ALTER SYSTEM and make the error message more
> > definitive:
>
> > postgres=# ALTER SYSTEM SET wal_level TO minimal;
> > ERROR: configuration is managed externally
>
> > As a bonus, if that GUC is set, we could even check at server startup
> > that all the configuration files are not writable by the postgres user,
> > and print a warning or refuse to start up if they are.
>
> I like this idea. The "bonus" is not optional though, because
> setting the files' ownership/permissions is the only way to be
> sure that the prohibition is even a little bit bulletproof.

Isn't this going to break pgbackrest restore then, which (AIUI, and was
mentioned upthread) writes recovery configs into postgresql.auto.conf?
Or do I misunderstand the proposal? I think it would be awkward if only
root users are able to run pgbackrest restore. I have added David to the
CC list to make him aware of this, in case he was not following this
thread.

The other candidate for breakage that was mentioned was pg_basebackup
-R, but I guess that could be worked around.

Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Wolfgang Walther 2024-03-20 09:39:20 Re: Regression tests fail with musl libc because libpq.so can't be loaded
Previous Message Peter Eisentraut 2024-03-20 09:25:11 Re: REVOKE FROM warning on grantor