Re: Possibility to disable `ALTER SYSTEM`
| От | Gabriele Bartolini |
|---|---|
| Тема | Re: Possibility to disable `ALTER SYSTEM` |
| Дата | |
| Msg-id | CA+VUV5p7mSeWcyWJWU_PDuLEh+gLJwovhuhb5+c8Y-f+XHhtPQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Possibility to disable `ALTER SYSTEM` (Magnus Hagander <magnus@hagander.net>) |
| Список | pgsql-hackers |
Hi Magnus,
On Mon, 11 Sept 2023 at 16:04, Magnus Hagander <magnus@hagander.net> wrote:
But to do that, there would need to be a very in-your-face warning in
the documentation about it like "note that this only disables the
ALTER SYSTEM command. It does not prevent a superuser from changing
the configuration remotely using other means".
Although I did not include any docs in the PoC patch, that's exactly the plan. So +1 from me.
Yes, this is marginally harder than saying ALTER SYSTEM SET
work_mem='1TB', but only very very marginally so. And from a security
perspective, there is zero difference.
Agree, but the primary goal is not security. Indeed, security requires a more holistic approach (and in my initial thread I deliberately did not mention all the knobs that the operator provides, with stricter and stricter default values, as I thought it was not relevant from a Postgres' PoV). However, as I explained in the patch PoC thread, the change is intended primarily to warn legitimate administrators in a configuration managed controlled environment that ALTER SYSTEM has been disabled for that system. These are environments where network access for a superuser is prohibited, but still possible for local SREs to log in via the container in the pod for incident resolution - very often this happens in high stress conditions and I believe that this gate will help them remind that if they want to change the settings they need to do it through the Kubernetes resources. So primarily: usability.
Another idea to solve the problem could be to instead introduce a
specific configuration file (either hardcoded or an
include_final_parameter=<path> parameter, in which case patroni or the
k8s operator could set that parameter on the command line and that
parameter only) that is parsed *after* postgresql.auto.conf and
thereby would override the manual settings. This file would explicilty
be documented as intended for this type of tooling, and when you have
a tool - whether patroni or another declarative operator - it owns
this file and can overwrite it with whatever it wants. And this would
also retain the ability to use ALTER SYSTEM SET for *other*
parameters, if they want to.
But that is exactly the whole point of this request: disable the last operation altogether. This option will easily give any operator (or deployment in a configuration management scenario) the possibility to ship a system that, out-of-the box, facilitates this one direction update of the configuration, allowing the observed state to easily reconcile with the desired one. Without breaking any existing deployment.
Stopping ALTER SYSTEM SET without actually preventing the superuser
from doing the same thing as they were doing before would to me be at
least as much of a hack as what patroni does today is.
Agree, but as I said above, that'd be at that point the role of an operator. An operator, at that point, will have the possibility to configure this knob in conjunction with others. A possibility that Postgres is not currently giving.
Postgres itself should be able to give this possibility, as these environments demand Postgres to address their emerging needs.
Thank you,
Gabriele
В списке pgsql-hackers по дате отправления: