Re: logfile subprocess and Fancy File Functions

Tom Lane wrote:

>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.
>
>
>
>

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