On Fri, Jun 13, 2014 at 11:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Fujii Masao <masao.fu...@gmail.com> writes: >> On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao <masao.fu...@gmail.com> wrote: >>> Some users enable log_disconnections in postgresql.conf to audit all >>> logouts. >>> But since log_disconnections is defined with PGC_BACKEND, it can be changed >>> at connection start. This means that any client (even nonsuperuser) can >>> freely >>> disable log_disconnections not to log his or her logout even when the >>> system admin >>> enables it in postgresql.conf. Isn't this problematic for audit? > >> That's harmful for audit purpose. I think that we should make >> log_disconnections PGC_SUSET rather than PGC_BACKEND in order >> to forbid non-superusers from changing its setting. Attached >> patch does this. > > TBH, this complaint seems entirely artificial. If somebody needs to audit > disconnections, and they see a connection record with no disconnection > record but the session's no longer there, they certainly know that a > disconnection occurred. And if there wasn't a server crash to explain it, > they go slap the wrist of whoever violated corporate policy by turning off > log_disconnections. Why do we need system-level enforcement of this? > > Moreover, your proposed fix breaks the entire point of the PGC_BACKEND > setting, which was to try to prevent disconnections from being logged > or not logged when the corresponding connection was not logged or logged > respectively. If an auditor wants the system to enforce that there are > matched pairs of those records, he's not exactly going to be satisfied by > being told that only superusers can cause them to not match. > > I wonder whether we should just get rid of log_disconnections as a > separate variable, instead logging disconnections when log_connections > is set. > > Another answer is to make both variables PGC_SIGHUP, on the grounds > that it doesn't make much sense for them not to be applied system-wide; > except that I think there was some idea that logging might be enabled > per-user or per-database using ALTER ROLE/DATABASE.
But, IIUC, since PGC_BACKEND parameters cannot be set per-role and per-database, such idea seems impractical. No? ISTM that there is no big user-visible problematic change of the behavior even if we redefine log_connections and log_disconnections as PGC_SIGHUP. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers