Re: Possibility to disable `ALTER SYSTEM`

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Gabriele Bartolini <gabriele(dot)bartolini(at)enterprisedb(dot)com>
Cc: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Possibility to disable `ALTER SYSTEM`
Date: 2023-09-08 14:55:47
Message-ID: 202309081455.mjyy7fyeb7xb@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2023-Sep-08, Gabriele Bartolini wrote:

> That is the point I highlighted in the initial post in the thread. We could
> make it readonly, but the returned error is misleading and definitely poor
> UX:
>
> ```
> postgres=# ALTER SYSTEM SET wal_level TO minimal;
> ERROR: could not open file "postgresql.auto.conf": Permission denied
> ```
>
> IMO we should clearly state that `ALTER SYSTEM` is deliberately disabled in
> a system, rather than indirectly hinting it through an inaccessible file.
> Not sure if I am clearly highlighting the fine difference here.

Come on. This is not a "fine difference" -- it's the difference between
a crummy hack and a real implementation of an important system
restriction.

I don't understand Tom's resistance to this request. I understand the
use case and I agree with Gabriele that this is a very simple code
change(*) that Postgres could make to help it get run better in a
different kind of environment than what we're accustomed to.

I've read that containers people consider services in a different light
than how we've historically seen them; they say "cattle, not pets".
This affects the way you think about these services. postgresql.conf
(all the PG configuration, really) is just a derived file from an
overall system description that lives outside the database server. You
no longer feed your PG servers one by one, but rather they behave as a
herd, and the herder is some container supervisor (whatever it's called).

Ensuring that the configuration state cannot change from within is
important to maintain the integrity of the service. If the user wants
to change things, the tools to do that are operated from outside; this
lets things like ancillary services to be kept in sync (say, start a
replica here, or a backup system there, or WAL archival/collection is
handled in this or that way). If users are allowed to change the config
from within they break things, and the supervisor program can't put
things together again.

I did not like the mention of COPY PROGRAM, though, and in principle I
do not support the idea of treating it the same way as ALTER SYSTEM. If
people are using that to write into postgresql.conf, then they deserve
all the hell they get when their containers break. I think trying to
restrict this outside of the privilege system is going to be more of a
wart than ALTER SYSTEM.

(*) To be proven. Let's see the patch.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Syntax error: function hell() needs an argument.
Please choose what hell you want to involve.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2023-09-08 14:56:15 Re: Adding a pg_get_owned_sequence function?
Previous Message Bruce Momjian 2023-09-08 14:52:10 Re: Document that server will start even if it's unable to open some TCP/IP ports