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

From Abhijit Menon-Sen
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id 20141227084729.GA2271@toroid.org
Whole thread Raw
In response to Re: pgaudit - an auditing extension for PostgreSQL  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: pgaudit - an auditing extension for PostgreSQL  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
At 2014-12-27 08:08:32 +0000, simon@2ndQuadrant.com wrote:
>
> > what if i want to audit different things for different users?
> 
> That is supported - you can provide a list of roles to be audit roles.

You can do that, but maybe it isn't quite enough to do what Jaime is
asking for. Not always, at least. Consider:

1. You want to audit select on foo by user jaime (only).
2. You want to audit update on bar by user simon (only).

So you do something like this:
   pgaudit.roles = 'audit1, audit2'
   grant select on foo to audit1;   grant update on bar to audit2;

Now if Jaime does select on foo or if Simon does update on bar, it'll be
logged. If user jaime does not have permission to do update on bar, and
if simon doesn't have permission to select on foo, everything is fine.

But there's no way to say *don't* audit select on foo by simon.

You could do something like "grant role audit1 to jaime" and then check
the audit-permissions of whichever audit role jaime is found at runtime
to inherit from. But in Stephen's original proposal, granting any audit
role to any user meant that everything they did would be logged.

-- Abhijit



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Next
From: Noah Misch
Date:
Subject: Re: Serialization exception : Who else was involved?