Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Fri, 23 Jul 2004, Andreas Pflug wrote:
>> What I'd like is
>>
>> SELECT pg_file_unlink('postgresql.conf.bak');
>> SELECT pg_file_write('postgresql.conf.tmp', 'listen_addresses=...');
>> SELECT pg_file_rename('postgresql.conf.tmp', 'postgresql.conf',
>> 'postgresql.conf.bak');
>> SELECT pg_reload_conf();
> I personally don't think the above is the correct approach to allowing
> configuration editing from remote.
I'm pretty much against allowing configuration editing from remote
altogether. It would raise the stakes tremendously in terms of what
an attacker can do once they've acquired a connection with superuser
rights. Remember that the above could be applied to pg_hba.conf,
pg_ident.conf, etc just as well as postgresql.conf. Not to mention
$HOME/.profile and other things the postgres user may own.
> It seems like the wrong level for the interface, and the file rename
> isn't atomic and pretending that it is may prove to be dangerous.
Well, editing postgresql.conf directly isn't very atomic either, with
most editors (which is why we made the postmaster only re-examine the
files upon SIGHUP).
A more cogent argument why remote editing is dangerous is that if you
screw up a config file, you may be unable to get in to fix your mistake.
I agree about the "level" issue though. If we want to officially
support this, something involving a super-sized form of SET would be
a lot more supportable in the long run.
regards, tom lane
