Re: Possibility to disable `ALTER SYSTEM`
| От | David G. Johnston |
|---|---|
| Тема | Re: Possibility to disable `ALTER SYSTEM` |
| Дата | |
| Msg-id | CAKFQuwaWhu0Y84JaVf+Vt4d6VQtRPhY0PEud8uM_Ostes=-dsA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Possibility to disable `ALTER SYSTEM` (Peter Eisentraut <peter@eisentraut.org>) |
| Список | pgsql-hackers |
On Tue, Feb 6, 2024 at 7:10 AM Peter Eisentraut <peter@eisentraut.org> wrote:
How about ALTER SYSTEM is disabled if the file
postgresql.auto.conf.disabled exists? This is somewhat similar to making
the file read-only, but doesn't risk other tools breaking when they
encounter such a file. And it's more obvious and self-explaining.
A separate configuration file would be self-documenting and able to always exist; the same properties as postgres.conf
ISTM the main requirement regardless of how the file system API is designed - assuming there is a filesystem API - is that the running postgres process be unable to write to the file. It seems immaterial how the OS admin accomplishes that goal.
The command line argument method seems appealing but it seems harder in that case to ensure that the postgres process be disallowed from modifyIng whatever file defines what should be run.
One concern with a file configuration is that if we require it to be present in the data directory that goes somewhat against the design of allowing configuration files to be placed anywhere by changing the config_file guc.
Any design should factor in the almost immediate need to be extended to prevent copy variants that touch the local filesystem or shell directly.
I was pondering a directory in pgdata where you could add *.disabled files indicating which features to disable. This is a bit more pluggable than a single configuration file but the later still seems better to me.
David J.
В списке pgsql-hackers по дате отправления: