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

From Abhijit Menon-Sen
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id 20140623183306.GK31357@toroid.org
Whole thread Raw
In response to Re: pgaudit - an auditing extension for PostgreSQL  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pgaudit - an auditing extension for PostgreSQL  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
At 2014-06-23 08:50:33 -0400, sfrost@snowman.net wrote:
> 
> I'm not a huge fan of adding this as a contrib module

I added it to the CF because we're interested in auditing functionality
for 9.5, and as far as I can tell, there's nothing better available. At
the moment, the contrib module has the advantage that it exists :-) and
works with 9.[34] (and could be made to work with 9.2, though I didn't
bother for the initial submission).

> unless we can be
> quite sure that there's a path forward from here to a rework of the
> logging in core which would actually support the features pg_audit is
> adding, without a lot of pain and upgrade issues.

What sort of pain and upgrade issues did you have in mind?

> I'd expect a catalog table or perhaps changes to pg_class (maybe other
> things also..) to define what gets logged.. 

Please explain?

(I wish extensions were able to add reloptions. That would have made it
relatively easy for us to implement per-object audit logging.)

> I'd also like to see the ability to log based on the connecting user,
> and we need to log under what privileges a command is executing

I imagine it's not useful to point out that you can do the former with
pgaudit (using ALTER ROLE … SET), and that we log the effective userid
for the latter (though maybe you had something more in mind)…

> and, really, a whole host of other things..

…but there's not a whole lot I can do with that, either.

Is the minimal set of auditing features that we would need in-core very
different from what pgaudit already has?

-- Abhijit



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: API change advice: Passing plan invalidation info from the rewriter into the planner?
Next
From: Heikki Linnakangas
Date:
Subject: Re: Minmax indexes