Re: Possibility to disable `ALTER SYSTEM`

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Joel Jacobson <joel(at)compiler(dot)org>, 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>
Subject: Re: Possibility to disable `ALTER SYSTEM`
Date: 2024-03-27 15:10:31
Message-ID: CA+TgmoabbXSpiRHE=CrNJFd9vBz-3tXMatAz=EUaAr1HrZqUjw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 27, 2024 at 11:01 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Uh, the above is clearly wrong. I think you mean "off" on the second line.

Woops. When the name changed from externally_managed_configuration to
allow_alter_system, the sense of it was reversed, and I guess Jelte
missed flipping the documentation references around. I likely would
have made the same mistake, but it's easily fixed.

> > +
> > + <para>
> > + Note that this setting cannot be regarded as a security feature. It
> > + only disables the <literal>ALTER SYSTEM</literal> command. It does not
> > + prevent a superuser from changing the configuration remotely using
>
> Why "remotely"?

This wording was suggested upthread. I think the point here is that if
the superuser is logging in from the local machine, it's obvious that
they can do whatever they want. The point is to emphasize that a
superuser without a local login can, too.

> "its"?

Yeah, that seems like an extra word.

> > + some outside mechanism. In such environments, using <command>ALTER
> > + SYSTEM</command> to make configuration changes might appear to work,
> > + but then may be discarded at some point in the future when that outside
>
> "might"

This does not seem like a mistake to me. I'm not sure why you think it is.

> > + mechanism updates the configuration. Setting this parameter to
> > + <literal>on</literal> can help to avoid such mistakes.
> > + </para>
>
> "off"

This is another case that needs to be fixed now that the sense of the
GUC is reversed. (We'd better make sure the code has the test the
right way around, too.)

> Is this really a patch we think we can push into PG 17. I am having my
> doubts.

If the worst thing that happens in PG 17 is that we push a patch that
needs a few documentation corrections, we're going to be doing
fabulously well.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2024-03-27 15:18:46 Re: Combine Prune and Freeze records emitted by vacuum
Previous Message Nathan Bossart 2024-03-27 15:08:26 Re: pg_upgrade failing for 200+ million Large Objects