Re: pgaudit - an auditing extension for PostgreSQL - Mailing list pgsql-hackers

On Fri, Jun 27, 2014 at 2:23 PM, Stephen Frost <sfrost@snowman.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