* Robert Haas (robertmhaas@gmail.com) 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.
I'm hopeful that my email from a few minutes ago provides a way to cover
all of the above, while still making it easy for users who just want to
say "audit everything this user does" or "audit everything which touches
this column".
Any auditing of superusers is going to be circumventable by those same
superusers if it's happening in the context of the PG process, so I'm
not sure why they would be any different under this scheme vs. some
other scheme.
Don't get me wrong- I agree completely that using the GRANT system isn't
ideal, but I don't see anyone proposing another way for an extension to
store metadata on catalog tables with the same granularity the GRANT
system provides and its dependency handling and ability to have default
values. We've been over that ground a number of times and I certainly
don't feel like we're any closer to solving it and I'd hate to see that
block pgaudit.
Put another way, if the requirement for pgaudit is that it has to solve
the metadata-on-catalogs-for-extensions problem, I think I'd rather just
move pgaudit into core instead, give it catalog tables, make it part of
the dependency system, provide syntax for it, etc. I'm pretty sure
that'd be easier and happen a lot faster.
Thanks!
Stephen