Re: pgaudit - an auditing extension for PostgreSQL

Поиск
Список
Период
Сортировка
От Abhijit Menon-Sen
Тема Re: pgaudit - an auditing extension for PostgreSQL
Дата
Msg-id 20140504142442.GF7706@toroid.org
обсуждение исходный текст
Ответ на Re: pgaudit - an auditing extension for PostgreSQL  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: pgaudit - an auditing extension for PostgreSQL
Список pgsql-hackers
At 2014-05-04 08:52:42 -0400, sfrost@snowman.net wrote:
>
> This also addresses things like anonymous DO blocks and functions
> then..?  With enough information to be useful for forensics?

For DML, it addresses anything that goes through InitPlan (which, via
ExecCheckRTPerms, calls the ExecutorCheckPerms_hook). Yes, that does
include table accesses within DO blocks:

LOG:  [AUDIT],2014-05-04 19:15:06.130771+05:30,ams,ams,ams,WRITE,DELETE,TABLE,public.a,do $$begin delete from a;
end;$$;

…and functions:

LOG:  [AUDIT],2014-05-04 19:16:20.336499+05:30,ams,ams,ams,DEFINITION,CREATE FUNCTION,,,create function x(int) returns
textas $$select b from a where a=$1;$$ language sql;
 
LOG:  [AUDIT],2014-05-04 19:16:48.112725+05:30,ams,ams,ams,FUNCTION,EXECUTE,FUNCTION,public.x,select * from x(3);
LOG:  [AUDIT],2014-05-04 19:16:48.112922+05:30,ams,ams,ams,READ,SELECT,TABLE,public.a,select * from x(3);

> We'd need to also consider permissions and how these are managed.

Yes. For pgaudit, we kept it simple and made pgaudit.log
superuser-only[1].

I haven't given much thought to this area, because I didn't know what
mechanism to use to set per-object auditing parameters. For a contrib
module, extensible reloptions would have been convenient. But in-core
auditing support could use a proper reloption, I suppose. It's a pity
that extensions can't add reloptions.

Personally, I don't think it's important to support GRANT-ing the
ability to set audit parameters. I think it would be reasonable even to
say that only the superuser could do it (but I can imagine people being
unhappy if the owner couldn't[2]).

Definitely lots to discuss.

-- Abhijit

1. I wish it were possible to prevent even the superuser from disabling  audit logging once it's enabled, so that if
someonegained superuser  access without authorisation, their actions would still be logged.  But I don't think there's
anyway to do this.
 

2. On the other hand, I can also imagine a superuser being justifiably  annoyed if she were to carefully configure
auditing,and random users  then enabled audit-everything for their newly-created tables and  filled the audit table
withjunk.
 



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: missing RelationCloseSmgr in FreeFakeRelcacheEntry?
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: 9.4 release notes