Re: Possibility to disable `ALTER SYSTEM`
Maciek Sakrejda <m.sakrejda@gmail.com>
From: Maciek Sakrejda <m.sakrejda@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Joel Jacobson <joel@compiler.org>, Andrew Dunstan <andrew@dunslane.net>, Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Magnus Hagander <magnus.hagander@redpill-linpro.com>,
"daniel@yesql.se" <daniel@yesql.se>
Date: 2024-03-14T21:14:29Z
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 →
-
Add allow_alter_system GUC.
- d3ae2a24f265 17.0 landed
-
Rename COMPAT_OPTIONS_CLIENT to COMPAT_OPTIONS_OTHER.
- de7e96bd0fc6 17.0 landed
-
Remove support for version-0 calling conventions.
- 5ded4bd21403 10.0 cited
On Thu, Mar 14, 2024 at 1:38 PM Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Mar 14, 2024 at 4:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > The patch-of-record contains no such wording. > > I plan to fix that, if nobody else beats me to it. > > > And if this isn't a > > security feature, then what is it? If you have to say to your > > (super) users "please don't mess with the system configuration", > > you might as well just trust them not to do it the easy way as not > > to do it the hard way. If they're untrustworthy, why have they > > got superuser? > > I mean, I feel like this question has been asked and answered before, > multiple times, on this thread. If you sincerely don't understand the > use case, I can try again to explain it. But somehow I feel like it's > more that you just don't like the idea, which is fair, but it seems > like a considerable number of people feel otherwise. I know I'm jumping into a long thread here, but I've been following it out of interest. I'm sympathetic to the use case, since I used to work at a Postgres cloud provider, and while our system intentionally did not give our end users superuser privileges, I can imagine other managed environments where that's not an issue. I'd like to give answering this question again a shot, because I think this has been a persistent misunderstanding in this thread, and I don't think it's been made all that clear. It's not a security feature: it's a usability feature. It's a usability feature because, when Postgres configuration is managed by an outside mechanism (e.g., as in a Kubernetes environment), ALTER SYSTEM currently allows a superuser to make changes that appear to work, but may be discarded at some point in the future when that outside mechanism updates the config. They may also be represented incorrectly in a management dashboard if that dashboard is based on the values in the outside configuration mechanism, rather than values directly from Postgres. In this case, the end user with access to Postgres superuser privileges presumably also has access to the outside configuration mechanism. The goal is not to prevent them from changing settings, but to offer guard rails that prevent them from changing settings in a way that will be unstable (revertible by a future update) or confusing (not showing up in a management UI). There are challenges here in making sure this is _not_ seen as a security feature. But I do think the feature itself is sensible and worthwhile. Thanks, Maciek