From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgaudit - an auditing extension for PostgreSQL |
Date: | 2014-06-30 13:13:31 |
Message-ID: | CA+TgmobZN5brTfkfJ9bh4zeUpYf-_ZSfaCY7GfpRx+OKfAA4kg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 27, 2014 at 2:23 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> I disagree with Stephen's proposal that this should be in core, or
>> that it needs its own dedicated syntax. I think contrib is a great
>> place for extensions like this. That makes it a whole lot easier for
>> people to develop customized vesions that meet particular needs they
>> may have, and it avoids bloating core with a bunch of stuff that is
>> only of interest to a subset of users. We spent years getting sepgsql
>> into a form that could be shipped in contrib without substantially
>> burdening core, and I don't see why this feature should be handed any
>> differently.
>
> I don't exactly see how an extension or contrib module is going to be
> able to have a reasonable catalog structure which avoids the risk that
> renaming an object (role, schema, table, column, policy) will break the
> configuration without being part of core.
At some level, I guess that's true, but a custom GUC would get you
per-role and per-database and a custom reloption could take it
further. A security label provider specifically for auditing can
already associate custom metadata with just about any SQL-visible
object in the system.
> Add on to that the desire for
> audit control to be a grant'able right along the lines of:
>
> GRANT AUDIT ON TABLE x TO audit_role;
>
> which allows a user who is not the table owner or a superuser to manage
> the auditing.
As Tom would say, I think you just moved the goalposts into the next
county. I don't know off-hand what that syntax is supposed to allow,
and I don't think it's necessary for pgaudit to implement that (or
anything else that you may want) in order to be a viable facility.
>> In fact, considering how much variation there is likely to be between
>> auditing requirements at different sites, I'm not sure this should
>> even be in contrib at this point. It's clearly useful, but there is
>> no requirement that every useful extension must be bundled with the
>> core server, and in fact doing so severely limits our ability to make
>> further changes.
>
> For my part, I do view auditing as being a requirement we should be
> addressing through core- and not just for the reasons mentioned above.
> We might be able to manage all of the above through an extension,
> however, as we continue to add capabilities and features, new types and
> methods, ways to extend the system, and more, auditing needs to keep
> pace and be considered a core feature as much as the GRANT system is.
I think the fact that pgaudit does X and you think it should do Y is a
perfect example of why we're nowhere close to being ready to push
anything into core. We may very well want to do that someday, but not
yet.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-06-30 13:24:57 | Re: RLS Design |
Previous Message | Beena Emerson | 2014-06-30 13:08:15 | Re: Priority table or Cache table |