Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension

Stephen Frost <sfrost@snowman.net> writes:
> * Joshua D. Drake (jd@commandprompt.com) wrote:
>> It seems to me that perhaps the solution is then to pull pg_audit
>> into user space and instead work on a general solution (an API?
>> custom backend?) that provides what is needed.

> I am planning on working on the necessary changes to core to include
> auditing capabilities.  Hopefully, that will go more smoothly.  I do not
> believe that auditing should or even can be an external module, indeed,
> pg_audit was exactly that attempt and, even with significant resources
> put into it over the past year, it falls far short of what any
> organization who is familiar with the capabilities in other RDBMSs would
> expect.  That doesn't mean that I feel it's bad- it's a step in the
> right direction, but it isn't a complete solution.

I'm fairly confused by your line of argument.  If auditing can be done
by non-core code, then there is no great urgency to have it as a contrib
module.  If it can't be done by non-core code, then creating a contrib
module is just a dead end that will soon leave nothing behind except
backwards-compatibility problems.  Our experience with pulling contrib
modules into core has not been good in that respect.

As far as I can tell, pg_audit at this point is most charitably described
as "experimental", and I'm not sure that we want to put it into contrib
on that basis.  Of late we've generally acted as though contrib modules
have the same kind of cross-version compatibility expectations that core
code does.  It seems to me that that sort of promise is *way* premature
in this case; but I'm not seeing any large red warnings in pgaudit.sgml
that the described facilities are subject to change.

Quite aside from the question of whether we're ready to put a stake in the
ground about user-visible features of an audit facility, there seem to be
a lot of technical issues here:

* Do we have adequate hooks in the backend with which auditing code can
detect events of interest (with acceptably low overhead)?  I dunno, but
if we do not, having a contrib module doesn't fix it.

* Do we have an adequate design for specifying which out of the possible
auditable events should be logged?  I dunno about this either, but it
seems like this is an area best kept out of core if at all possible.
The design space seems pretty vast and I doubt that one size will fit all,
or needs to fit all.

* Do we have an appropriate mechanism for performing logging of events
that we've decided to log?  Here I think the answer is unquestionably
"no"; basing audit logging on the existing elog mechanism with no changes
is simply broken.  elog is designed to be flexible about whether messages
get reported and to where, which is exactly what you do *not* want for
audit logs.  This might not be too hard to fix, eg add another elevel with
hard-wired rules about where it goes ... but the current patch didn't do
that.  A larger problem is that maybe the audit message stream shouldn't
go to the postmaster log in the first place, but someplace else.

* Do we have an appropriate mechanism for configuring the audit facility?
I'm not totally sure, but again I think that the existing GUC mechanisms
were not designed for this sort of thing and are probably too easy to
subvert.  (It might be hopeless to try to ensure that superusers can't
escape auditing, but as it stands pg_audit doesn't even pretend to try.
Even without the possibility of intentional subversion, there are too
many ways to turn auditing off by accident.)

On the whole, I think sticking this into contrib is premature.  What it
does today could be done just as well as a third-party extension.  What
it doesn't do today, we should work on, but I'm unconvinced that having
this in contrib will make it easier to get there.
        regards, tom lane