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

From Stephen Frost
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id 20150122005002.GA3854@tamriel.snowman.net
Whole thread Raw
In response to Re: pgaudit - an auditing extension for PostgreSQL  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: pgaudit - an auditing extension for PostgreSQL
List pgsql-hackers
* Jim Nasby (Jim.Nasby@BlueTreble.com) wrote:
> On 1/21/15 5:38 PM, Stephen Frost wrote:
> >Being startup-only won't help if the user is a superuser.
>
> Crap, I thought postgresql.auto.conf was handled as an #include and therefore you could still preempt it via
postgresql.conf

It's not just that..  Having superuser access should really be
considered equivilant to having a shell as the unix user that postgres
is running as.

> >If this is being done for every execution of a query then I agree- SQL
> >or plpgsql probably wouldn't be fast enough.  That doesn't mean it makes
> >sense to have pgaudit support calling a C function, it simply means that
> >we need to find another way to configure auditing (which is what I think
> >I've done...).
>
> I'm still nervous about overloading this onto the roles system; I think it will end up being very easy to
accidentallybreak. But if others think it'll work then I guess I'm just being paranoid. 

Break in which way..?  If you're saying "it'll be easy for a user to
misconfigure" then I might agree with you- but documentation and
examples can help to address that.  If you're worried that future PG
hacking will break it, well, I tend to doubt the GRANT piece is the area
of concern there- the recent development work is really around event
triggers and adding new object classes; the GRANT components have been
reasonably stable for the past few years.
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Next
From: Kouhei Kaigai
Date:
Subject: Re: Parallel Seq Scan