Re: pgaudit - an auditing extension for PostgreSQL

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, MauMau <maumau307(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com>
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Date: 2015-01-22 00:50:02
Message-ID: 20150122005002.GA3854@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Jim Nasby (Jim(dot)Nasby(at)BlueTreble(dot)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 accidentally break. 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2015-01-22 01:07:16 Re: Parallel Seq Scan
Previous Message Jim Nasby 2015-01-22 00:05:55 Re: pgaudit - an auditing extension for PostgreSQL