Jim, * Jim Nasby (jim.na...@bluetreble.com) wrote: > +1. In particular I'm very concerned with the idea of doing this via roles, > because that would make it trivial for any superuser to disable auditing. The > only good option I could see to provide this kind of flexibility would be > allowing the user to provide a function that accepts role, object, etc and > make return a boolean. The performance of that would presumably suck with > anything but a C function, but we could provide some C functions to handle > simple cases.
Superusers will be able to bypass, trivially, anything that's done in
the process space of PG. The only possible exception to that being an
SELinux or similar solution, but I don't think that's what you were
getting at.
I certainly don't think having the user provide a C function to specify
what should be audited as making any sense- if they can do that, they
can use the same hooks pgaudit is using and skip the middle-man. As for
the performance concern you raise, I actually don't buy into it at all.
It's not like we worry about the performance of checking permissions on
objects in general and, for my part, I like to think that's because it's
pretty darn quick already.
> That said, I think the best idea at this stage is either log everything or
> nothing. We can always expand upon that later.
We've already got those options and they are, clearly, insufficient for
a large number of our users.
Thanks,
Stephen
signature.asc
Description: Digital signature
