Re: Auditing extension for PostgreSQL (Take 2) - Mailing list pgsql-hackers

From David Steele
Subject Re: Auditing extension for PostgreSQL (Take 2)
Date
Msg-id 54EB4E56.7050102@pgmasters.net
Whole thread Raw
In response to Re: Auditing extension for PostgreSQL (Take 2)  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Auditing extension for PostgreSQL (Take 2)
List pgsql-hackers
Hi Stephen,

Thanks for your review.  All fixed except for comments below:

On 2/17/15 10:34 AM, Stephen Frost wrote:
>> +    /*
>> +     * Check privileges granted indirectly via role memberships. We do this in
>> +     * a separate pass to minimize expensive indirect membership tests.  In
>> +     * particular, it's worth testing whether a given ACL entry grants any
>> +     * privileges still of interest before we perform the has_privs_of_role
>> +     * test.
>> +     */
>
> I'm a bit on the fence about this..  Can you provide a use-case where
> doing this makes sense..?  Does this mean I could grant admin_role1 to
> audit and then get auditing on everything that user1 has access to?
> That seems like it might be useful for environments where such roles
> already exist though it might end up covering more than is intended..

The idea is that if there are already ready-made roles to be audited
then they don't need to be reconstituted for the audit role.  You could
just do:

grant admin_role to audit;
grant user_role to audit;

Of course, we could list multiple roles in the pg_audit.role GUC, but I
thought this would be easier to use and maintain since there was some
worry about GUCs being fragile when they refer to database objects.

>> +################################################################################
>> +# test.pl - pgAudit Unit Tests
>> +################################################################################
>
> This is definitiely nice..
>
>> diff --git a/doc/src/sgml/pgaudit.sgml b/doc/src/sgml/pgaudit.sgml
>> new file mode 100644
>> index 0000000..f3f4ab9
>> --- /dev/null
>> +++ b/doc/src/sgml/pgaudit.sgml
>> @@ -0,0 +1,316 @@
>> +<!-- doc/src/sgml/pgaudit.sgml -->
>> +
>> +<sect1 id="pgaudit" xreflabel="pgaudit">
>> +  <title>pg_audit</title>
>
> There seems to be a number of places which are 'pgaudit' and a bunch
> that are 'pg_audit'.  I'm guessing you were thinking 'pg_audit', but
> it'd be good to clean up and make them all consistent.

Fixed, though I still left the file name as pgaudit.sgml since all but
one module follow that convention.

>> +    <para>
>> +      Session auditing allows the logging of all commands that are executed by
>> +      a user in the backend.  Each command is logged with a single entry and
>> +      includes the audit type (e.g. <literal>SESSION</literal>), command type
>> +      (e.g. <literal>CREATE TABLE</literal>, <literal>SELECT</literal>) and
>> +      statement (e.g. <literal>"select * from test"</literal>).
>> +
>> +      Fully-qualified names and object types will be logged for
>> +      <literal>CREATE</literal>, <literal>UPDATE</literal>, and
>> +      <literal>DROP</literal> commands on <literal>TABLE</literal>,
>> +      <literal>MATVIEW</literal>, <literal>VIEW</literal>,
>> +      <literal>INDEX</literal>, <literal>FOREIGN TABLE</literal>,
>> +      <literal>COMPOSITE TYPE</literal>, <literal>INDEX</literal>, and
>> +      <literal>SEQUENCE</literal> objects as well as function calls.
>> +    </para>
>
> Ah, you do have a list of what objects you get fully qualified names
> for, nice.  Are there obvious omissions from that list..?  If so, we
> might be able to change what happens with objectAccess to include them..

It seems like these are the objects where having a name really matters.
 I'm more interested in using the deparse code to handle fully-qualified
names for additional objects rather than adding hooks.

>> +    <sect3>
>> +      <title>Examples</title>
>> +
>> +      <para>
>> +        Set <literal>pgaudit.log = 'read, ddl'</literal> in
>> +        <literal>postgresql.conf</literal>.
>> +      </para>
>
> Perhaps I missed it, but it'd be good to point out that GUCs can be set
> at various levels.  I know we probably say that somewhere else, but it's
> particularly relevant for this.

Yes, it's very relevant for this patch.  Do you think it's enough to
call out the functionality, or should I provide examples?  Maybe a
separate section just for this concept?

Patch v2 is attached for all changes except the doc change above.

--
- David Steele
david@pgmasters.net

Attachment

pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: Primary not sending to synchronous standby
Next
From: David Steele
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL