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

From Stephen Frost
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id 20140625144025.GU16098@tamriel.snowman.net
Whole thread Raw
In response to Re: pgaudit - an auditing extension for PostgreSQL  (Abhijit Menon-Sen <ams@2ndquadrant.com>)
Responses Re: pgaudit - an auditing extension for PostgreSQL  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
* Abhijit Menon-Sen (ams@2ndquadrant.com) wrote:
> At 2014-06-25 00:10:55 -0400, sfrost@snowman.net wrote:
> > For my part, the nexts steps might be to consider how you'd migrate
> > what you've provided for configuration into catalog tables
>
> I must confess that I do not understand what needs to be migrated into
> the catalog tables, or why. Of course, pgaudit.log must be renamed, but
> why can't it continue to be a GUC setting? (Fujii-san suggested that it
> be integrated with log_statement. I'm not sure what I think of that, but
> it's certainly one possibility.)

What I was getting at are things like "what tables are to be audited,
and for what users?".  I thought pg_audit had this capability today
(isn't that part of the request for the rlsextension field..?) and I'd
want to see something like

AUDIT SELECT ON table1 FOR role1;

> > and how we'd address the concerns raised elsewhere regarding catalog
> > access in cases where we're not in a transaction
>
> …by not putting things into the catalog?

I just don't see that as viable.

> If we implement per-object auditing configuration in-core, it can use a
> real reloption. Apart from that, I don't see a really good reason yet to
> put more things into the database.

I don't think the auditing will be so simple as being able to be
supported by a single additional field or with just reloption.  Consider
what's happening on the RLS thread.

> > We'd also end up re-working the code to be called as part of PG core
> > rather than through hook functions, of course, but I don't think those
> > changes would be too bad compared to figuring out the other issues.
>
> You're right (but we'd still want to use event triggers). Maybe it would
> make sense to have an auditing hook that we can sprinkle calls to in all
> the interesting places, though.

Not against using event triggers if they make sense..  I'm not 100% sure
that I agree that they do, but I haven't looked at it closely enough to
really form an opinion.

> > Additionally, thought towards what the SQL-level syntax would be is
> > another key point- would the main command be 'ALTER AUDIT'?
>
> (I have some thoughts about that, but I'll discuss them later when I
> have a bit more time to present them properly.)

I find it really helps to try and define an SQL syntax as it can help
build an understanding of what's going to be in the catalogs and what
features are expected.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: [PATCH] log_{directory,filename} doc fixes
Next
From: "MauMau"
Date:
Subject: Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop]