From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, David Steele <david(at)pgmasters(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Subject: | Re: PostgreSQL Audit Extension |
Date: | 2016-02-05 23:20:51 |
Message-ID: | CA+TgmobNA0FKoS3gweWNqPifRnpcTyF0aSQr+ZQeXF_F5V2ZXw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 5, 2016 at 1:16 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> An in-core auditing solution would provide us with proper grammar
> support, ability to directly mark objects for auditing in the catalog,
> allow us to much more easily maintain auditing capability over time as
> a small incremental bit of work for each new feature (with proper
> in-core infrastructure for it) and generally be a far better technical
> solution. Leveraging the GRANT system is quite cute, and does work, but
> it's certainly non-intuitive and is only because we've got no better
> way, due to it being implemented as an extension.
Yeah, I agree. Let me clarify my position: I'm not opposed to in-core
auditing. I'm also not in favor of it. If somebody makes a proposal
in that area, I'll probably have an opinion on it, but until then I
don't. What I'm opposed to is shipping this in core rather than
letting it continue to exist outside core. I see no benefit to that
and some possible downsides that I think justify rejecting it. Of
course other people are entitled to their own opinions; what I'm
saying is: that's my opinion. If somebody came along with a proposal
to put auditing in core that offered the advantages you cite here,
none of my objections to this would be objections to that. Would I
have other objections? Maybe, but not necessarily.
For example, one thing that occurs to me is that, at least in some
cases, we've got a built-in way of finding out all of the objects that
a query touches: the list of PlanInvalItems. Is it a clever idea to
try to drive auditing off that list, or a terrible idea? I'm not
sure, but clearly if it's a good idea that would make this largely
self-maintaining, which IMHO completely changes the calculus about
whether it's worth doing. Also, we've got quite a few
ObjectAddress-related facilities in the core system now that know how
to do various kinds of things with any sort of SQL-accessible object
in the system. Leveraging that infrastructure seems like a big plus.
I'd be much more likely to support a proposal that does this stuff in
a generic way that touches every SQL object type, and contains little
or no hard-wired information about particular SQL object types in the
auditing code itself. I'm not blind to the fact that auditing
relation access is more valuable than auditing text search parser
access, but it's harder to predict what we might think about the next
three SQL object types we add, and I don't want the burden to be on
the people who add that stuff to teach auditing about it if somebody
wants that. Rather, I think the auditing system should know about
everything we've got, and which stuff actually gets audited should be
a matter of configuration.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-02-06 00:44:35 | Re: proposal: make NOTIFY list de-duplication optional |
Previous Message | Tom Lane | 2016-02-05 22:11:29 | First-draft release notes for next week's back-branch releases |