Re: pgaudit - an auditing extension for PostgreSQL - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id CAHGQGwFLVB0=ygEEvbYkNBWBXQEt63STJ2=r_e=y356eQ=Js+Q@mail.gmail.com
Whole thread Raw
In response to Re: pgaudit - an auditing extension for PostgreSQL  (David Steele <david@pgmasters.net>)
Responses Re: pgaudit - an auditing extension for PostgreSQL  (David Steele <david@pgmasters.net>)
Re: pgaudit - an auditing extension for PostgreSQL  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Thu, Feb 19, 2015 at 12:25 AM, David Steele <david@pgmasters.net> wrote:
> Hi Fujii,
>
> Thanks for taking a look at the patch.  Comments below:
>
> On 2/18/15 6:11 AM, Fujii Masao wrote:
>> On Wed, Feb 18, 2015 at 1:26 AM, David Steele <david@pgmasters.net> wrote:
>>> On 2/17/15 10:23 AM, Simon Riggs wrote:
>>>> I vote to include pgaudit in 9.5, albeit with any changes. In
>>>> particular, David may have some changes to recommend, but I haven't
>>>> seen a spec or a patch, just a new version of code (which isn't how we
>>>> do things...).
>>>
>>> I submitted the new patch in my name under a separate thread "Auditing
>>> extension for PostgreSQL (Take 2)" (54E005CC.1060605@pgmasters.net)
>>
>> I played the patch version of pg_audit a bit and have basic comments about
>> its spec.
>>
>> The pg_audit doesn't log BIND parameter values when prepared statement is used.
>> Seems this is an oversight of the patch. Or is this intentional?
>
> It's actually intentional - following the model I talked about in my
> earlier emails, the idea is to log statements only.

Is this acceptable for audit purpose in many cases? Without the values,
I'm afraid that it's hard to analyze what table records are affected by
the statements from the audit logs. I was thinking that identifying the
data affected is one of important thing for the audit. If I'm malicious DBA,
I will always use the extended protocol to prevent the values from being
audited when I execute the statement.

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PATCH: adaptive ndistinct estimator v3 (WAS: Re: [PERFORM] Yet another abort-early plan disaster on 9.3)
Next
From: "David G. Johnston"
Date:
Subject: Re: Add min and max execute statement time in pg_stat_statement