Re: Possibility to disable `ALTER SYSTEM`

Поиск
Список
Период
Сортировка
От Greg Sabino Mullane
Тема Re: Possibility to disable `ALTER SYSTEM`
Дата
Msg-id CAKAnmmJ0WAA3bs6P2G8ktVYGamE8D7P+xMkZbVQHE7pW8fjgMQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Possibility to disable `ALTER SYSTEM`  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Possibility to disable `ALTER SYSTEM`  (Jelte Fennema-Nio <postgres@jeltef.nl>)
Список pgsql-hackers
As a bonus, if that GUC is set, we could even check at server startup that all the configuration files are not writable by 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 brand new security system. There are so many ways this could go wrong if we start having separate permissions for some of our files. In addition to backups and other tools that need to write to the conf files as the postgres user, what about systems that create a new cluster automatically e.g. Patroni? It will now need elevated privs just to create the conf files and assign the new ownership to them. Lots of moving pieces there and ways things could go wrong. So a big -1 from me, as they say/ :)

Cheers,
Greg
 

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

Предыдущее
От: Alexander Lakhin
Дата:
Сообщение: Test 031_recovery_conflict.pl is not immune to autovacuum
Следующее
От: Dave Cramer
Дата:
Сообщение: Re: query_id, pg_stat_activity, extended query protocol