Re: Possibility to disable `ALTER SYSTEM`

Поиск
Список
Период
Сортировка
От Michael Banck
Тема Re: Possibility to disable `ALTER SYSTEM`
Дата
Msg-id 65faaccf.5d0a0220.b1779.5914@mx.google.com
обсуждение исходный текст
Ответ на Re: Possibility to disable `ALTER SYSTEM`  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Possibility to disable `ALTER SYSTEM`  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
Hi,

On Tue, Mar 19, 2024 at 10:51:50AM -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
> > Perhaps we could make that even better with a GUC though. I propose a 
> > GUC called 'configuration_managed_externally = true / false". If you set 
> > it to true, we prevent ALTER SYSTEM and make the error message more 
> > definitive:
> 
> > postgres=# ALTER SYSTEM SET wal_level TO minimal;
> > ERROR:  configuration is managed externally
> 
> > 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.
> 
> I like this idea.  The "bonus" is not optional though, because
> setting the files' ownership/permissions is the only way to be
> sure that the prohibition is even a little bit bulletproof.

Isn't this going to break pgbackrest restore then, which (AIUI, and was
mentioned upthread) writes recovery configs into postgresql.auto.conf? 
Or do I misunderstand the proposal? I think it would be awkward if only
root users are able to run pgbackrest restore. I have added David to the
CC list to make him aware of this, in case he was not following this
thread.

The other candidate for breakage that was mentioned was pg_basebackup
-R, but I guess that could be worked around.


Michael



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: REVOKE FROM warning on grantor
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Catalog domain not-null constraints