From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com> |
Subject: | Re: pgaudit - an auditing extension for PostgreSQL |
Date: | 2014-10-14 12:57:05 |
Message-ID: | 20141014125704.GR28859@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Abhijit,
* Abhijit Menon-Sen (ams(at)2ndQuadrant(dot)com) wrote:
> As before, the pgaudit code is at https://github.com/2ndQuadrant/pgaudit
> I did a quick round of testing to make sure things still work.
Thanks!
I had a very interesting discussion about auditing rules and the need to
limit what gets audited by user, table, column, policy, etc recently and
an idea came up (not my own) about how to support that granularity
without having to modify the existing PG catalogs or use GUCs or
reloptions, etc. It goes something like this-
Create an 'audit' role.
Every command run by roles which are granted to the 'audit' role are
audited.
Every 'select' against tables which the 'audit' role has 'select' rights
on are audited. Similairly for every insert, update, delete.
Every 'select' against columns of tables which the 'audit' role has
'select' rights on are audited- and only those columns are logged.
Similairly for every insert, update, delete.
etc, etc, throughout the various objects which can have permissions.
We don't currently have more granular permissions for roles (it's
"all-or-nothing" currently regarding role membership) and so if we want
to support things like "audit all DML for this role" we need multiple
roles, eg:
Create an 'audit_rw' role. DML commands run by roles granted to the
'audit_rw' role are audited. Similairly for 'audit_ro' or other
permutations.
The 'audit*' roles would need to be configured for pgAudit in some
fashion, but that's acceptable and is much more reasonable than having
an independent config file which has to keep track of the specific roles
or tables being audited.
The 'audit_ro' and 'audit_rw' roles lead to an interesting thought about
supporting something like which I want to mention here before I forget
about it, but probably should be a new thread if folks think it's
interesting:
GRANT role1 (SELECT) to role2;
Such that 'role2' would have role1's SELECT rights, but not role1's
INSERT, or UPDATE, or DELETE rights. There would be more complexity if
we want to support this for more than just normal relations, of course.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | MauMau | 2014-10-14 12:59:15 | Re: [9.4 bug] The database server hangs with write-heavy workload on Windows |
Previous Message | Abhijit Menon-Sen | 2014-10-14 12:38:34 | Re: pgaudit - an auditing extension for PostgreSQL |