Re: Auditing and Postgres 7.3 - Mailing list pgsql-hackers
From | Murray Prior Hobbs |
---|---|
Subject | Re: Auditing and Postgres 7.3 |
Date | |
Msg-id | 3C4EB30F.3040907@efone.com Whole thread Raw |
In response to | Auditing and Postgres 7.3 (Gavin Sherry <swm@linuxworld.com.au>) |
Responses |
Re: Auditing and Postgres 7.3
Re: Auditing and Postgres 7.3 |
List | 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 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 >> >
pgsql-hackers by date: