Skip site navigation (1) Skip section navigation (2)

Re: Auditing and Postgres 7.3

From: Murray Prior Hobbs <murray(at)efone(dot)com>
To: Justin Clift <justin(at)postgresql(dot)org>
Cc: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Auditing and Postgres 7.3
Date: 2002-01-23 12:56:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
the lack of a true full audit trail capabiity in postgres is perhaps 
it's biggest fundamental weakness as a "commercial" use system

it has "commercial" use viability at this moment like the XT had 
"commercial" use viabilty in the early 80's

ie it's demand driven in a market where many (un aware or unconcrned) 
people/businesses are prepared to pay for something that's really not 
the real thing (hope i havn't broken and stupid copyright laws there)

in fact. if i was to want to design a database system for "commercial" 
use the very first thing i would start with would be the audit system

objects oriented? no, after audit

referenential integrety?, no, after audit

really - even just on a practicality basis the audit is essential

there needs to be a front end to the database - a completely new layer - 
that layer feeds the database and no other and that layer is itself the 
audit trail

it should be possible to run an audit trail backwards against a database 
and undo everything back to an earlier state (assuming that this is done 
in standalone mode)

the audit then IS the database - or rather it IS the data - all of it - 
and ideally it wold be in a form that is almost human readable

just MHO


Justin Clift wrote:

>Hi Gavin,
>I can see the usefulness of this concept from a "Data Security" point of
>At one place I worked, it was known one of the marketing people had a
>reputation of gathering customer details before leaving a job, just so
>he had something to bargain a pay increase with for his next job.  Don't
>know why people hire a guy like that (I wouldn't), but these people
>It should definitely be optional, and if not turned on for an object I
>don't think it should have an associated noticable performance penalty.
>My thought is useful, but not sure how urgent when compared to other
>+ Justin
>Gavin Sherry wrote:
>>Hi all,
>>I've been thinking implementing auditing for Postgres 7.3 and wanted to
>>see if anyone had any thoughts about it.
>>Auditing would allow a user to log queries executed upon different
>>'schema' objects - I use the loose sense of the word here. The user would
>>be able to define the type of query - insert, delete, etc - as well as
>>choose to log only those queries which were successful or otherwise.
>>The superuser would be able to audit unprivileged users. Unprivileged
>>users would only be able to produce an audit trail upon objects which
>>he/she owns or has been granted audit privileges to.
>>The audit trail would be written either to a new internal system table,
>>pg_audit, or optionally a file on the file system. I imagine that an
>>external program would also be needed to read/dump the audit trail.
>>So what would an audit trail consist of?
>>query type
>>query result (successful|unsuccessful)
>>audit object oid
>>I haven't really thought about this too hard just yet but thought I'd see
>>if people considered this to be a useful addition to Postgres or not, or
>>if I was going about this the wrong way.
>>---------------------------(end of broadcast)---------------------------
>>TIP 4: Don't 'kill -9' the postmaster

In response to


pgsql-hackers by date

Next:From: Gavin SherryDate: 2002-01-23 13:01:21
Subject: Re: Auditing and Postgres 7.3
Previous:From: Lamar OwenDate: 2002-01-23 12:49:36
Subject: Red Hat 7.2 Regression failures (Re: pltcl build problem on FreeBSD (was: Re: pltlc and pltlcu problems))

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group