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
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 |