Re: pgaudit - an auditing extension for PostgreSQL - Mailing list pgsql-hackers

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Mon, Jun 30, 2014 at 9:39 AM, Stephen Frost <sfrost@snowman.net> wrote:
> >> I think the fact that pgaudit does X and you think it should do Y is a
> >> perfect example of why we're nowhere close to being ready to push
> >> anything into core.  We may very well want to do that someday, but not
> >> yet.
> >
> > That's fine- but don't push something in which will make it difficult to
> > add these capabilities later (and, to be clear, I'm not asking out of
> > pipe dreams and wishes but rather after having very specific discussions
> > with users and reviewing documents like NIST 800-53, which is publically
> > available for anyone to peruse).
>
> I don't think that's a valid objection.  If we someday have auditing
> in core, and if it subsumes what pgaudit does, then whatever
> interfaces pgaudit implements can be replaced with wrappers around the
> core functionality, just as we did for text search.

I actually doubt that we'd be willing to do what we did for text search
again.  Perhaps I'm wrong, which would be great, but I doubt it.

> But personally, I think this patch deserves to be reviewed on its own
> merits, and not the extent to which it satisfies your requirements, or
> those of NIST 800-53.

eh?  The focus of this patch is to add auditing to PG and having very
clearly drawn auditing requirements of a very large customer isn't
relevant?  I don't follow that logic at all.  In fact, I thought the
point of pgaudit was specifically to help address the issues which are
being raised from this section of our user base (perhaps not those who
follow NIST, but at least those organizations with similar interests..).

> As I said before, I think auditing is a
> complicated topic and there's no guarantee that one solution will be
> right for everyone.  As long as we keep those solutions out of core,
> there's no reason that multiple solutions can't coexist; people can
> pick the one that best meets their requirements.  As soon as we start
> talking about something putting into core, the bar is a lot higher,
> because we're not going to put two auditing solutions into core, so if
> we do put one in, it had better be the right thing for everybody.

I agree that auditing is a complicated topic.  Given the dearth of
existing auditing solutions, I seriously doubt we're going to actually
see more than one arise.  I'd much rather focus on an in-core solution
which allows the mechanism by which auditing logs are produced by
through an extension (perhaps through hooks in the right places) but the
actual definition of *what* gets audited to be defined through SQL with
a permissions system that works with the rest of the system.

What I'm getting at is this- sure, different users will want to have
their audit logs be in different formats (JSON, XML, CSV, whatever), or
sent via different means (logged to files, sent to syslog, forwarded on
to a RabbitMQ system, splunk, etc), but the definition of what gets
audited and allowing individuals other than the owners to be able to
modify the auditing is much more clear-cut to me as there's only so many
different objects in the system and only so many operations which can be
performed on them..  This strikes me as similar to security labels, as
was discussed previously.

> I
> don't even think we should be considering that at this point; I think
> the interesting (and under-discussed) question on this thread is
> whether it even makes sense to put this into contrib.  That means we
> need some review of the patch for what it is, which there hasn't been
> much of, yet.

Evidently I wasn't very clear on this point but my concerns are about it
going into contrib, which is what's been proposed, because I worry about
an eventual upgrade path from contrib to an in-core solution.  I'm also
a bit nervous that a contrib solution might appear 'good enough' to
enough committers that the push-back on an in-core solution would lead
to us never having one.  These concerns are, perhaps, not very palatable
but I feel they're real enough to bring up.

contrib works quite well for stand-alone sets of functions which don't,
and never will, have any in-core direct grammar or catalog support.
While pgaudit doesn't have those today, I'd like to see *auditing* in
PG, eventually, which has both a real grammar and a catalog definition.
Thanks,
    Stephen