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

Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:
> I agree with Stephen's statement that the audit configuration
> shouldn't be managed in flat files.  If somebody wants to do that in
> an extension, fine, but I don't think we should commit anything into
> our source tree that works that way.  The right way to manage that
> kind of configuration is with GUCs, or reloptions, or (security)
> labels, or some other kind of catalog structure.  Renaming an object
> shouldn't be able to break auditing, but if the audit configuration is
> a list of table names in a file somewhere, it will.

Thanks for your thoughts on this.

> 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.  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.  I'm not against implementing capabilities through contrib
modules, provided the goals of the feature can be met that way.  In a
way, sepgsql is actually a good example for this- the module provides
the implementation, but all of the syntax and catalog information is
actually in core.  An implementation similar to that for auditing might
be workable, but I don't see pgaudit as being that.

> 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.
Thanks,
    Stephen