Re: Audit of logout

On Sat, Jun 21, 2014 at 12:59 PM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/13/2014 07:29 AM, Tom Lane wrote:
>> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
>>> On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao
>>> <masao(dot)fujii(at)gmail(dot)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.
>
> This whole argument seems wrong unless I'm missing something:
>
> test=# set log_connections = on;
> ERROR: parameter "log_connections" cannot be set after connection start
> test=# set log_disconnections = off;
> ERROR: parameter "log_disconnections" cannot be set after connection
> start

You can change log_connections/disconnections via connection option as follows

$ grep log_disconnections $PGDATA/postgresql.conf
log_disconnections = on

$ psql -U hoge -d "options='-c log_disconnections=off'"
=> show log_disconnections ;
log_disconnections
--------------------
off
(1 row)

=> \du
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------+-----------
hoge | | {}
postgres | Superuser, Create role, Create DB, Replication | {}

>> I wonder whether we should just get rid of log_disconnections as a
>> separate variable, instead logging disconnections when
>> log_connections is set.
>
>
> That might be a good idea though.

David pointed the merit of keeping those two parameters separate upthread
and I understand his thought.
http://www.postgresql.org/message-id/1402675662004-5807224.post@n5.nabble.com

Regards,

--
Fujii Masao