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

From David Steele
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id 54CFE2BF.9030000@pgmasters.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
List pgsql-hackers
On 1/27/15 4:08 AM, Abhijit Menon-Sen wrote:

> Anyway, I think it's reasonably clear now that pgaudit is unlikely to
> make it into 9.5 in any form, so I'll find something else to do.

That's unfortunate.  I've been following this thread for a while with
some interest (and anticipation).

The role-base approach being considered may strike some as a misuse of
the role system, but to my eye it is syntactically very close to how
Oracle does auditing prior to 12c.  Say you wanted to audit selects on
the table hr.employee:

Oracle: AUDIT SELECT ON hr.employee;
pgaudit: GRANT SELECT ON hr.employee TO audit; (assuming audit is the
role defined by pgaudit.roles)

Object-based auditing in Oracle would be very easy to migrate to the
grants needed for pgaudit.  In addition, if an AUDIT command were
introduced later in core, it would be easy to migrate from pgaudit to
AUDIT assuming the syntax was similar to grant, which seems plausible.

Unified auditing in 12c brings together the AUDIT command and DBMS_FGA
under the concept of audit polices.  That type of granularity might be
something to shoot for eventually, but I think having a way to do
auditing similar to what is available in pre-12c covers most use cases
and would certainly be a big step forward for Postgres.

--
- David Steele
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_check_dir comments and implementation mismatch
Next
From: Stephen Frost
Date:
Subject: Re: Odd behavior of updatable security barrier views on foreign tables