Re: Proposal: leave a hint when switching logging away from stderr - Mailing list pgsql-hackers

On 08/09/2013 03:40 PM, Tom Lane wrote:
> In principle I see the risk, but I don't think I've ever seen an actual
> report of someone getting confused this way by an on-the-fly logging
> parameter change.  Whereas there are numerous examples in the archives
> of people not realizing that "pg_ctl -l foo" doesn't necessarily mean
> that all the useful log output is in file foo.  (Usually it's because
> they're using a logging setup chosen by some packager, not by themselves.)
> So I'm feeling that what you're suggesting is solving a different and
> far less pressing problem than what I'm on about.

No question.  That's why I suggested it as a TODO item instead of anyone
working on it right now.

The main benefit I see for this is security, especially with ALTER
SYSTEM SET pending.   Switching log destinations is a good way to cover
your tracks if you have some kind of temporary superuser access (for
example, by exploiting a SECURITY DEFINER function).  If the switch were
recorded somewhere other than the new log location, it would provide a
little more sleuthing information for later auditors.

> I did think a little bit about how to do it.  For parameters that affect
> where the logging collector writes data (probably only log_directory is
> worth special handling), it would be quite easy to make the got_SIGHUP
> code segment in syslogger.c emit a log message just before switching the
> active value.  However, if you want something similar for log_destination,
> syslog_facility, syslog_ident, or event_source, it's far more problematic
> because those settings affect the behavior of individual processes, and
> so there's no unique point where we're switching from one log target to
> another.  We could have the postmaster report a value change but it's
> likely that that message would not appear very close to the end of the
> messages directed to the old target.

But wait, there's more complications: what if you're switching
log_directory because the disk on the old log location is full?  Then we
*can't* emit a log entry on switch, because we can't write it.

Like I said, complicated out of proportion to be benefit, at least right
now.

> Another point here is that if you're tailing the current log file,
> a plain old rotation (no parameter change anywhere) would also cut
> you off without obvious notice. 

Yeah, I'm not concerned about that, since the location of the new log is
predictable.

> Maybe we shouldn't think about this
> as a "change of parameter" problem, but just say it's worth emitting
> an "end of log file" message anytime we're about to change to a new log
> file, no matter the reason.  But again, that's specific to the logging
> collector case and doesn't help with any other log target.  I also note
> that I'm not familiar with any system logging tool that emits such
> messages.

I'm not familiar with other system logging tools.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com