Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters
От | Stefan Kaltenbrunner |
---|---|
Тема | Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters |
Дата | |
Msg-id | 520015DA.9090603@kaltenbrunner.cc обсуждение исходный текст |
Ответ на | Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
On 08/05/2013 09:53 PM, Alvaro Herrera wrote: > Tom Lane escribió: > >> What Josh seems to be concerned with in this thread is the question of >> whether we should support an installation *policy decision* not to allow >> ALTER SYSTEM SET. Not because a particular set of parameters is broken, >> but just because somebody is afraid the DBA might break things. TBH >> I'm not sure I buy that, at least not as long as ALTER SYSTEM is a >> superuser feature. There is nothing in Postgres that denies permissions >> to superusers, and this doesn't seem like a very good place to start. > > Someone made an argument about this on IRC: GUI tool users are going to > want to use ALTER SYSTEM through point-and-click, and if all we offer is > superuser-level access to the feature, we're going to end up with a lot > of people running with superuser privileges just so that they are able > to tweak inconsequential settings. This seems dangerous. indeed it is > > The other issue is that currently you can only edit a server's config if > you are logged in to it. If we permit SQL-level access to that, and > somebody who doesn't have access to edit the files blocks themselves > out, there is no way for them to get a working system *at all*. thinking more about that - is there _ANY_ prerequisite of an application that can be completely reconfigured over a remote access protocol and solved the reliability and security challenges of that to a reasonable degree? Stefan
В списке pgsql-hackers по дате отправления: