> On 15 Mar 2024, at 03:58, Bruce Momjian <br...@momjian.us> wrote: > > On Thu, Mar 14, 2024 at 07:43:15PM -0400, Robert Haas wrote: >> On Thu, Mar 14, 2024 at 5:15 PM Maciek Sakrejda <m.sakre...@gmail.com> wrote: >>> 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. >> >> This is what I would have said if I'd tried to offer an explanation, >> except you said it better than I would have done. > > I do think the docs need to clearly say this is not a security feature.
A usability feature whose purpose is to guard against a superuser willingly acting against how the system is managed, or not even knowing how it is managed, does have a certain security feature smell. We've already had a few CVE's filed against usability features so I don't think Tom's fears are at all ungrounded. Another quirk for the documentation of this: if I disable ALTER SYSTEM I would assume that postgresql.auto.conf is no longer consumed, but it still is (and still need to be), so maybe "enable/disable" is the wrong choice of words? -- Daniel Gustafsson
