Re: Possibility to disable `ALTER SYSTEM`

Поиск
Список
Период
Сортировка
От Jelte Fennema-Nio
Тема Re: Possibility to disable `ALTER SYSTEM`
Дата
Msg-id CAGECzQSR+F2G7VX6v2tJkJ9QcieQ2Lr732ir5ozhQ36L-8AnjQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Possibility to disable `ALTER SYSTEM`  (Greg Sabino Mullane <htamfids@gmail.com>)
Ответы Re: Possibility to disable `ALTER SYSTEM`  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, 20 Mar 2024 at 14:04, Greg Sabino Mullane <htamfids@gmail.com> wrote:
>>
>> As a bonus, if that GUC is set, we could even check at server startup that all the configuration files are not
writableby the postgres user, 
>> and print a warning or refuse to start up if they are.
>
>
> Ugh, please let's not do this. This was bouncing around in my head last night, and this is really a quite radical
change- especially just to handle the given ask, which is to prevent a specific command from running. Not implement a
brandnew security system. There are so many ways this could go wrong if we start having separate permissions for some
ofour files. In addition to backups and other tools that need to write to the conf files as the postgres user, what
aboutsystems that create a new cluster automatically e.g. Patroni? It will now need elevated privs just to create the
conffiles and assign the new ownership to them. Lots of moving pieces there and ways things could go wrong. So a big -1
fromme, as they say/ :) 


Well put. I don't think the effort of making all tooling handle this
correctly is worth the benefit that it brings. afaict everyone on this
thread that actually wants to use this feature would be happy with the
functionality that the current patch provides (i.e. having
postgresql.auto.conf writable, but having ALTER SYSTEM error out).



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

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: sslinfo extension - add notbefore and notafter timestamps
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Have pg_basebackup write "dbname" in "primary_conninfo"?