Re: Auditing and Postgres 7.3

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

m

Justin Clift wrote:

>Hi Gavin,
>
>I can see the usefulness of this concept from a "Data Security" point of
>view.
>
>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
>exist.
>
>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
>improvements.
>
>:)
>
>+ 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?
>>
>>timestamp
>>query type
>>query
>>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.
>>
>>Gavin
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 4: Don't 'kill -9' the postmaster
>>
>