Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> 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.
Agreed, but what else are you going to do? You can't have random
unprivileged users changing settings that affect other users, even
if those settings are somehow "safe". And what is more to the point
in this thread, having an additional shutoff that prevents even superusers
from doing it doesn't reduce the temptation for everyone to make
themselves superuser all the time.
> 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*.
True. So, if they were smart enough to prevent themselves from changing
any settings remotely, they have no feature. And if they weren't, having
such a blocking capability didn't really help them either.
These are both valid worries, but what design is going to make them
better? Other than forgetting about ALTER SYSTEM entirely?
regards, tom lane