On 1/20/15 2:20 PM, Robert Haas wrote:
On Tue, Jan 20, 2015 at 1:05 AM, Abhijit Menon-Sen<a...@2ndquadrant.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.
+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.
That said, I think the best idea at this stage is either log everything or
nothing. We can always expand upon that later.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
