Re: pgaudit - an auditing extension for PostgreSQL

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Date: 2014-07-30 18:29:47
Message-ID: 20140730182947.GC16422@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> Actually, thinking more, Stephen Frost mentioned that the auditing
> system has to modify database _state_, and dumping/restoring the state
> of an extension might be tricky.

This is really true of any extension which wants to attach information
or track things associated with roles or other database objects. What
I'd like to avoid is having an extension which does so through an extra
table or through reloptions or one of the other approaches which exists
in contrib and which implements a capability we're looking at adding to
core as we'd then have to figure out how to make pg_upgrade deal with
moving such a configuration from the extension's table or from
reloptions into SQL commands which work against the version of PG which
implements the capability in core.

Using auditing as an example, consider this scenario:

pgaudit grows a table which is used to say "only audit roles X, Y, Z"
(or specific tables, or connections from certain IPs, etc).

A patch for PG 10.1 is proposed which adds the ability to enable
auditing for specific roles.

My concern is:

pg_upgrade then has to detect, understand, and implement a migration
path from 10.0-with-pgaudit to 10.1-in-core-auditing.

or

The PG 10.1 patch has to ensure that it doesn't break, harm, or
interfere with what pgaudit is doing in its per-role auditing.

or

The PG 10.1 patch is bounced because what pgaudit does is considered
"good enough" and it's already in contrib (though I don't believe this
will ever be the case while pgaudit exists as an extension- see
below).

From my perspective, it's pretty clear that we don't have any good
way for any extension, today, to have metadata properly associated
with database objects- such that renames, upgrades, dependency
issues, etc, are properly addressed and handled; nor are extensions
able to extend the grammar; and there is a concern that extensions may
not always be properly loaded, a serious concern when the role of that
extension is auditing.

Hope that helps.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-07-30 18:34:51 Re: pgaudit - an auditing extension for PostgreSQL
Previous Message Robert Haas 2014-07-30 18:02:29 Re: Proposal: Incremental Backup