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

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Ah, ok.
>
> Pushed that, but some further notes:

Thanks! Looking much better.

> * The actual audit reports ought to be ereport() not elog(). I made them
> so but did not insert an errcode(). ISTM that it would likely be a good
> thing to assign a not-used-for-any-other-purpose errcode for this, but I'm
> not terribly sure what category to put it in.

Right, I had seen that too and had intended to change it, but somehow
missed it in the other changes I was doing. I'll take a look at the
categories and try to figure out what makes sense.

> * The comments in the code betray utter ignorance of how logging actually
> works, in particular this:
>
> * Administrators can choose which log level the audit log is to be logged
> * at. The default level is LOG, which goes into the server log but does
> * not go to the client. Set to NOTICE in the regression tests.

I had rewored that last night and will reword it again to be more clear.

> All the user has to do is change client_min_messages and he'll see all the
> reports, which means if you think that letting the user see the audit
> reports is a security problem then you have a hole a mile wide.

There are certainly use-cases for this where that's not an issue and
also ones where the user wouldn't be able to use pg_audit due to this.

I'll update the docs to make the risk of this clear. At least for the
use-cases we've been involved in, they've not been concerned about this.
Still, any thoughts you have on this would certainly be welcome. I've
been thinking about how we might re-route and tag messages in the
backend for a number of years and I feel like this summer I'll have
resources and time to spend working towards it. Providing a way to
decide if a message should be sent only to the server log, or only to
the client, or to an external system (syslog, pgQ, rabbitMQ, etc), or to
some combination of those, is definitely one of the items on that list.

> (I assume BTW that we're not considering it a security problem that
> superusers can trivially escape auditing.)

No, that's entirely understood and expected, which is one of the reasons
it'd be good to reduce the number of superusers running around.

Thanks!

Stephen