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

Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Fri, Jun 27, 2014 at 2:23 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > 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.

Ugh.  Yes, we could implement a lot of things using per-object GUCs and
reloptions.  We could do the same for columns with custom attoptions.
For my part, that design looks absolutely horrible to me for
more-or-less everything.  I certainly don't feel like it's the solution
which extension authors are looking for and will be happy with, nor do I
feel it's the right answer for our users.

> > 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.

Perhaps I should have used the same argument on the RLS thread..
Instead, I realized that you and others were right- we don't want to
implement and commit something which would make adding the features
being asked for very difficult to do in the future.  The point of the
command above is to allow a role *other* than the table owner to
control the auditing on the table.  It's important in certain places
that the auditor have the ability to control the auditing and *only*
the auditing- not drop the table or change its definition.

I'm also not asking for this to be implemented today in pgaudit but
rather to point out that we should have a design which at least allows
us to get to the point where these features can be added.  Perhaps
there's a path to allowing the control I'm suggesting here with the
existing pgaudit design and with pgaudit as an extension- if so, please
speak up and outline it sufficiently that we can understand that path
and know that we're not putting ourselves into a situation where we
won't be able to support that flexibility.

> > 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.

That's fine- but don't push something in which will make it difficult to
add these capabilities later (and, to be clear, I'm not asking out of
pipe dreams and wishes but rather after having very specific discussions
with users and reviewing documents like NIST 800-53, which is publically
available for anyone to peruse).
Thanks,
    Stephen