Re: pgaudit - an auditing extension for PostgreSQL

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, 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-20 20:20:36
Message-ID: CA+TgmobEB_etWuhHyiFv3irfe_nYZNG7_0N4YDvQ7L0N2UdLYw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 20, 2015 at 1:05 AM, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> wrote:
> So when I'm trying to decide what to audit, I have to:
>
> (a) check if the current user is mentioned in .roles; if so, audit.
>
> (b) check if the current user is a descendant of one of the roles
> mentioned in .roles; if not, no audit.
>
> (c) check for permissions granted to the "root" role and see if that
> tells us to audit.
>
> Is that right? If so, it would work fine. I don't look forward to trying
> to explain it to people, but yes, it would work (for anything you could
> grant permissions for).

I think this points to fundamental weakness in the idea of doing this
through the GRANT system. Some people are going want to audit
everything a particular user does, some people are going to want to
audit all access to particular objects, and some people will have more
complicated requirements. Some people will want to audit even
super-users, others especially super-users, others only non
super-users. None of this necessarily matches up to the usual
permissions framework.

>> Have you considered splitting pgaudit.c into multiple files, perhaps
>> along the pre/post deparse lines?
>
> If such a split were done properly, then could the backwards-compatible
> version be more acceptable for inclusion in contrib in 9.5? If so, I'll
> look into it.

We're not going to include code in contrib that has leftovers in it
for compatibility with earlier source trees. That's been discussed on
this mailing list many times and the policy is clear.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-01-20 20:24:00 Re: Merging postgresql.conf and postgresql.auto.conf
Previous Message Jeff Davis 2015-01-20 20:13:32 Re: PATCH: decreasing memory needlessly consumed by array_agg