On 1/20/15 2:20 PM, Robert Haas wrote:
> On Tue, Jan 20, 2015 at 1:05 AM, Abhijit Menon-Sen<ams@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
superuserto disable auditing. The only good option I could see to provide this kind of flexibility would be allowing
theuser to provide a function that accepts role, object, etc and make return a boolean. The performance of that would
presumablysuck 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