Re: pgaudit - an auditing extension for PostgreSQL

From: David Steele <david(at)pgmasters(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Date: 2015-02-02 20:49:03
Message-ID: 54CFE2BF.9030000@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)pgmasters(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-02-02 20:56:08 Re: Odd behavior of updatable security barrier views on foreign tables
Previous Message Robert Haas 2015-02-02 20:48:33 Re: pg_check_dir comments and implementation mismatch