Re: Possibility to disable `ALTER SYSTEM`

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Possibility to disable `ALTER SYSTEM`
Дата
Msg-id CAKFQuwZBT0wzEPxAQzJchb75NLjXMEka4nNxFHbKdvh4+fbvvQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Possibility to disable `ALTER SYSTEM`  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Possibility to disable `ALTER SYSTEM`  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tuesday, January 30, 2024, Tom Lane <tgl@sss.pgh.pa.us> wrote:

My larger point here is that trying to enforce restrictions on
superusers *within* Postgres is simply not a good plan, for
largely the same reasons that Robert questioned making the
GUC mechanism police itself.  It needs to be done outside,
either at the filesystem level or via some other kernel-level
security system.


The idea of adding a file to the data directory appeals to me.

optional_runtime_features.conf
alter_system=enabled
copy_from_program=enabled
copy_to_program=disabled

If anyone tries to use disabled features the system emits an error:

ERROR: Cannot send copy output to program, action disabled by host.

My main usability question is whether restart required is an acceptable restriction.

Making said file owned by root (or equivalent) and only readable by the postgres process user suffices to lock it down.  Refusing to start if the file is writable, and at least one feature is disabled can be considered, with a startup option to bypass that check if desired.

David J.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Smith
Дата:
Сообщение: src/bin/pg_upgrade/t/004_subscription.pl test comment fix
Следующее
От: Peter Smith
Дата:
Сообщение: Re: Synchronizing slots from primary to standby