Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> 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.
I agree. Aren't we rather too far into feature freeze to be debating possible provision of a remote config facility and API?
If we provide it, I would suggest a setting that turns it off - maybe even make that the default. (re arguments about COPY - maybe we should be able to off server side COPY too).
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
