From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension |
Date: | 2015-05-14 17:38:49 |
Message-ID: | 6454.1431625129@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> At least on dromedary, this seems to be the problem:
>>
>> pg_audit.c: In function 'stack_pop':
>> pg_audit.c:387: warning: format '%ld' expects type 'long int', but argument 3 has type 'int64'
>> pg_audit.c: In function 'stack_valid':
>> pg_audit.c:406: warning: format '%ld' expects type 'long int', but argument 3 has type 'int64'
>> pg_audit.c:406: warning: format '%ld' expects type 'long int', but argument 4 has type 'int64'
>> pg_audit.c: In function 'log_audit_event':
>> pg_audit.c:676: warning: format '%ld' expects type 'long int', but argument 4 has type 'int64'
>> pg_audit.c:676: warning: format '%ld' expects type 'long int', but argument 5 has type 'int64'
>>
>> Will push a fix shortly and we'll see what happens.
> Ah, ok.
Pushed that, but some further notes:
* The actual audit reports ought to be ereport() not elog(). I made them
so but did not insert an errcode(). ISTM that it would likely be a good
thing to assign a not-used-for-any-other-purpose errcode for this, but I'm
not terribly sure what category to put it in.
* The comments in the code betray utter ignorance of how logging actually
works, in particular this:
* Administrators can choose which log level the audit log is to be logged
* at. The default level is LOG, which goes into the server log but does
* not go to the client. Set to NOTICE in the regression tests.
All the user has to do is change client_min_messages and he'll see all the
reports, which means if you think that letting the user see the audit
reports is a security problem then you have a hole a mile wide.
(I assume BTW that we're not considering it a security problem that
superusers can trivially escape auditing.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-05-14 18:22:17 | Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension |
Previous Message | Tom Lane | 2015-05-14 17:22:42 | pgsql: Fix portability issue in pg_audit. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-05-14 17:42:45 | Re: trust authentication behavior |
Previous Message | Andres Freund | 2015-05-14 17:18:11 | Re: Final Patch for GROUPING SETS |