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-21 03:01:11
Message-ID: 20150121030111.GB3062@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim,

* Jim Nasby (Jim(dot)Nasby(at)BlueTreble(dot)com) wrote:
> +1. In particular I'm very concerned with the idea of doing this via roles, because that would make it trivial for any superuser to disable auditing. The only good option I could see to provide this kind of flexibility would be allowing the user to provide a function that accepts role, object, etc and make return a boolean. The performance of that would presumably suck with anything but a C function, but we could provide some C functions to handle simple cases.

Superusers will be able to bypass, trivially, anything that's done in
the process space of PG. The only possible exception to that being an
SELinux or similar solution, but I don't think that's what you were
getting at.

I certainly don't think having the user provide a C function to specify
what should be audited as making any sense- if they can do that, they
can use the same hooks pgaudit is using and skip the middle-man. As for
the performance concern you raise, I actually don't buy into it at all.
It's not like we worry about the performance of checking permissions on
objects in general and, for my part, I like to think that's because it's
pretty darn quick already.

> That said, I think the best idea at this stage is either log everything or nothing. We can always expand upon that later.

We've already got those options and they are, clearly, insufficient for
a large number of our users.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-01-21 03:44:52 Re: [Pgbuildfarm-members] [HACKERS] Reducing buildfarm disk usage: remove temp installs when done
Previous Message Stephen Frost 2015-01-21 02:58:12 Re: pgaudit - an auditing extension for PostgreSQL