Re: Auditing extension for PostgreSQL (Take 2)

Поиск
Список
Период
Сортировка
От Sawada Masahiko
Тема Re: Auditing extension for PostgreSQL (Take 2)
Дата
Msg-id CAD21AoBFs2sA31Y+zgioQYfiXc0vGEOM3GcgouNc_AH00QCCow@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Auditing extension for PostgreSQL (Take 2)  (David Steele <david@pgmasters.net>)
Ответы Re: Auditing extension for PostgreSQL (Take 2)  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
On Wed, Mar 25, 2015 at 12:23 PM, David Steele <david@pgmasters.net> wrote:
>> On Wed, Mar 25, 2015 at 12:38 AM, David Steele <david@pgmasters.net> wrote:
>>>> 2. OBJECT auditing does not work before adding acl info to pg_class.rel_acl.
>>>> In following situation, pg_audit can not audit OBJECT log.
>>>> $ cat postgresql.conf | grep audit
>>>> shared_preload_libraries = 'pg_audit'
>>>> pg_audit.role = 'hoge_user'
>>>> pg_audit.log = 'read, write'
>>>> $ psql -d postgres -U hoge_user
>>>> =# create table hoge(col int);
>>>> =# select * from hoge;
>>>> LOG:  AUDIT: SESSION,3,1,READ,SELECT,,,select * from hoge;
>>>>
>>>> OBJECT audit log is not logged here since pg_class.rel_acl is empty
>>>> yet. (Only logged SESSION log)
>>>> So after creating another unconcerned role and grant any privilege to that user,
>>>> OBJECT audit is logged successfully.
>>>
>>> Yes, object auditing does not work until some grants have been made to
>>> the audit role.
>>>
>>>> =# create role bar_user;
>>>> =# grant select on hoge to bar_user;
>>>> =# select * from hoge;
>>>> LOG:  AUDIT: SESSION,4,1,READ,SELECT,,,select * from hoge;
>>>> LOG:  AUDIT: OBJECT,4,1,READ,SELECT,TABLE,public.hoge,select * from hoge;
>>>>
>>>> The both OBJCET and SESSION log are logged.
>>>
>>> Looks right to me.  If you don't want the session logging then disable
>>> pg_audit.log.
>>>
>>> Session and object logging are completely independent from each other:
>>> one or the other, or both, or neither can be enabled at any time.
>>
>> It means that OBJECT log is not logged just after creating table, even
>> if that table is touched by its owner.
>> To write OBJECT log, we need to grant privilege to role at least. right?
>
> Exactly.  Privileges must be granted to the audit role in order for
> object auditing to work.
>

The table owner always can touch its table.
So does it lead that table owner can get its table information while
hiding OBJECT logging?

Also I looked into latest patch again.
Here are two review comment.

1.
> typedef struct
> {
>    int64 statementId;
>   int64 substatementId;
Both statementId and substatementId could be negative number.
I think these should be uint64 instead.

2.
I got ERROR when executing function uses cursor.

1) create empty table (hoge table)
2) create test function as follows.

create function test() returns int as $$
declare   cur1 cursor for select * from hoge;   tmp int;
begin   open cur1;   fetch cur1 into tmp;  return tmp;
end$$
language plpgsql ;

3) execute test function (got ERROR)
=# select test();
LOG:  AUDIT: SESSION,6,1,READ,SELECT,,,selecT test();
LOG:  AUDIT: SESSION,6,2,FUNCTION,EXECUTE,FUNCTION,public.test,selecT test();
LOG:  AUDIT: SESSION,6,3,READ,SELECT,,,select * from hoge
CONTEXT:  PL/pgSQL function test() line 6 at OPEN
ERROR:  pg_audit stack is already empty
STATEMENT:  selecT test();

It seems like that the item in stack is already freed by deleting
pg_audit memory context (in MemoryContextDelete()),
before calling stack_pop in dropping of top-level Portal.

Regards,

-------
Sawada Masahiko



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

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: Parallel Seq Scan
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Error with index on unlogged table