Re: pgaudit - an auditing extension for PostgreSQL
| От | Abhijit Menon-Sen |
|---|---|
| Тема | Re: pgaudit - an auditing extension for PostgreSQL |
| Дата | |
| Msg-id | 20150121080404.GB5990@toroid.org обсуждение исходный текст |
| Ответ на | Re: pgaudit - an auditing extension for PostgreSQL (Stephen Frost <sfrost@snowman.net>) |
| Ответы |
Re: pgaudit - an auditing extension for PostgreSQL
|
| Список | pgsql-hackers |
[After a discussion on IRC with Stephen…] At 2015-01-20 21:47:02 -0500, sfrost@snowman.net wrote: > > Review the opening of this email though and consider that we could > look at "what privileges has the audit role granted to the current > role?" as defining what is to be audited. Right, I understand now how that would work. I'll try to find time to (a) implement this, (b) remove the backwards-compatibility code, and (c) split up the USE_DEPARSE_FUNCTIONS stuff. > > For example, what if I want to see all the tables created and > > dropped by a particular user? > > I hadn't been intending to address that with this scheme, but I think > we have that by looking for privilege grants where the audit role is > the grantee and the role-to-be-audited the grantor. For CREATE, yes, with a bit of extra ACL-checking code in the utility hook; but I don't think we'll get very far without the ability to log ALTER/DROP too. :-) So there has to be some alternative mechanism for that, and I'm hoping Robert (or anyone!) has something in mind. > Well, I was primairly digging for someone to say "yes, the object > access stuff will be reworked to be based on event triggers, thus > removing the need for the object access bits". (This doesn't entirely make sense to me, but it's tangential anyway, so I won't comment on it for now.) -- Abhijit
В списке pgsql-hackers по дате отправления: