On 1/20/15 9:01 PM, Stephen Frost wrote:
* 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.
Not if the GUC was startup-only. That would allow someone with OS access to the
server to prevent a Postgres superuser from disabling it.
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.
I was only mentioning C because of performance concerns. If SQL or plpgsql is
fast enough then there's no need.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
