* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 21, 2015 at 7:05 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:
> > I'm still nervous about overloading this onto the roles system; I think it
> > will end up being very easy to accidentally break. But if others think it'll
> > work then I guess I'm just being paranoid.
>
> I agree with you.  I don't hear anyone who actually likes that
> proposal except for Stephen.  The list of people who don't like it
> seems to include the patch author, which strikes me as a rather
> significant point.

Just to clarify- this concept isn't actually mine but was suggested by a
pretty sizable PG user who has a great deal of familiarity with other
databases.  I don't mean to try and invoke the 'silent majority' but
rather to make sure folks don't think this is my idea alone or that it's
only me who thinks it makes sense. :)  Simon had weighed in earlier
with, iirc, a comment that he thought it was a good approach also,
though that was a while ago and things have changed.

I happen to like the idea specifically because it would allow regular
roles to change the auditing settings (no need to be a superuser or to
be able to modify postgresql.conf/postgresql.auto.conf), it would
provide the level of granularity desired, would follow table, column,
role changes, renames, drops, recreations, the dependency system would
function as expected, etc, while keeping it as an extension, which I
understood to be pretty desirable, especially initially.

* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 21, 2015 at 1:42 AM, Abhijit Menon-Sen <a...@2ndquadrant.com> 
> wrote:
> > At 2015-01-20 20:36:39 -0500, robertmh...@gmail.com wrote:
> >> I think this is throwing the baby out with the bathwater.  Neither C
> >> functions nor all-or-nothing are going to be of any practical use.
> >
> > Do you see some approach that has a realistic chance of making 9.5 and
> > would also actually be worth putting into 9.5? Suggestions very welcome.
>
> Well, I'm still of the view that there's little to lose by having this
> remain out-of-core for a release or three.  We don't really all agree
> on what we want, and non-core code can evolve a lot faster than core
> code, so what's the rush?

Being out of core makes it unusable in production environments for a
large number of organizations. :/

> I'm coming around to the view that we're going to need fairly deep
> integration to make this work nicely.  It seems to me that the natural
> way of controlling auditing of a table is with table or column options
> on that table, but that requires either an extensible reloptions
> framework that we don't have today, or that it be in the core server.
> Similarly, the nice way of controlling options on a user is some
> property attached to the user: audit operations X, Y, Z when performed
> by this user.

This is basically the same position which I held about a year ago when
we were discussing this, but there was quite a bit of push-back on
having an in-core solution, from the additional catalog tables to making
the grammar larger and slowing things down.  For my 2c, auditing is more
than valuable enough to warrant those compromises, but I'm not anxious
to spend time developing an in-core solution only to get it shot down
after all the work has been put into it.

Still, if folks have come around to feeling like an in-core solution
makes sense, I'm certainly willing to work towards making that happen;
it's, after all, what I've been interested in for years. :)

> If you held a gun to my head and said, we must have something this
> release, I'd probably go for a GUC with a value that is a
> comma-separated list of role:operation:object triplets, like this:
>
> audit_stuff = 'alice:*:*, *:delete:*, bob:*:table secret'
>
> ...read as:
>
> - Audit everything alice does.
> - Audit all deletes by anyone.
> - Audit all access by bob to table secret.

And this approach doesn't address any of the issues mentioned above,
unfortunately, which would make it pretty difficult to really use.  I
think I'd rather deal with pgaudit being outside of the tree than pursue
an approach which has so many issues.

        Thanks!

                Stephen

Attachment: signature.asc
Description: Digital signature

Reply via email to