Re: pgaudit - an auditing extension for PostgreSQL

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>
Cc: Ian Barwick <ian(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Date: 2014-06-23 12:36:43
Message-ID: CAHGQGwHO3+E2eYwK7nfUEQv3WYrLHPpU7YM-cmkUy6+aSXbPuw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 23, 2014 at 7:51 PM, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> wrote:
> (I'm replying as co-author of pgaudit.)
>
> At 2014-06-23 19:15:39 +0900, masao(dot)fujii(at)gmail(dot)com wrote:
>>
>> You added this into CF, but its patch has not been posted yet. Are you
>> planning to make a patch?
>
> It's a self-contained contrib module. I thought Ian had posted a
> tarball, but it looks like he forgot to attach it (or decided to
> provide only a Github link). I've attached a tarball here for
> your reference.
>
>> > Planned future improvements include:
>> >
>> > 1. Additional logging facilities, including to a separate audit
>> > log file and to syslog, and potentially logging to a table
>> > (possibly via a bgworker process). Currently output is simply
>> > emitted to the server log via ereport().
>> >
>> > 2. To implement per-object auditing configuration, it would be nice
>> > to use extensible reloptions (or an equivalent mechanism)
>>
>> Is it possible to implement these outside PostgreSQL by using hooks?
>
> There are some unresolved questions with #2 because the extensible
> reloptions patch seems to have lost favour, but I'm pretty sure we
> could figure out some alternative.
>
>> If not, it might be better to implement audit feature in core from the
>> beginning.
>
> Sure, we're open to that possibility. Do you have any ideas about what
> an in-core implementation should do/look like?

I don't have good idea about that. But maybe we can merge pgaudit.log
into log_statement for more flexible settings of what to log.

BTW I found that pgaudit doesn't log bind parameters when prepared
statements are executed. I'm feeling this behavior is not good for audit
purpose. Thought?

Also I got only the following log message when I executed "PREPARE hoge AS
INSERT INTO mytbl VALUES($1)" and "EXECUTE hoge(1)". This means that
obviously we cannot track the statements via PREPARED command...

LOG: [AUDIT],2014-06-23
21:14:53.667059+09,postgres,postgres,postgres,WRITE,INSERT,TABLE,postgres.mytbl,execute
hoge(1);

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-06-23 12:50:33 Re: pgaudit - an auditing extension for PostgreSQL
Previous Message Stephen Frost 2014-06-23 12:36:02 Re: Use a signal to trigger a memory context dump?