Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: open source PostgreSQL not supportable? (Was: Challenging SQL Query Problem. Can you solve it?)

Re: open source PostgreSQL not supportable? (Was: Challenging SQL Query Problem. Can you solve it?)

From: HansF <News.Hans_at_telus.net>
Date: Fri, 06 Jan 2006 19:11:44 GMT
Message-Id: <pan.2006.01.06.19.11.35.972069@telus.net>


On Fri, 06 Jan 2006 18:25:40 +0000, Justin L. Kennedy wrote:

> In comp.databases.postgresql DA Morgan <damorgan_at_psoug.org> wrote:

>> The laws are intended to make sure that the audit trail prevents system
>> administrators and DBAs from making unaudited changes. So root and all
>> system/DBA passwords plus physical access to the server.

>
> Once you have root, you pretty much have everything needed to make any
> unaudited changes you want. How does Oracle solve this problem? For
> example, given root, what is to stop someone from opening up the tables in
> a hex editor as they appear on the hard disk?

Redo logs with built-in checksums at several levels? Offsite redo log auto-shipment capability? Streams?

I suspect it's not so much a case of not being able to make changes as being able to easily detect when unauthorized (as well as authorized) changes have occurred and what those changes affect.

And detect them in such a way that the auditors and LEA can determine with authority that they have occurred, as well as narrow the field of search for the possible perps.

(I'd like to see anyone, including Oracle's developers, with enough knowledge to be able to get ALL the points of consistency changed correctly by hand. Add the automatic off-server log shipping, and allow that server to have a completely different set of passwords, and the probability of unauditable data tampering becomes vanishingly small.)

The gotcha with some of the other (non-Oracle) locking and consistency mechanisms in place is that (in some cases) reports that are generated can be the result of dirty reads. Which implies the specific data did not occur at any point in the database in a stable and fully reproducible state. Which in turn defeats the guarantee that an auditor needs to be able to stamp a report as 'representing the true state of the information'.

To be able to accomplish that level of guarantee would often require the application be modelled, designed and implemented with that situation in mind - and the environment would then be able to ensure that no access outside that permitted by the application is possible. It's that last part that hurts.

-- 
Hans Forbrich                           
Canada-wide Oracle training and consulting
mailto: Fuzzy.GreyBeard_at_gmail.com   
*** Top posting [replies] guarantees I won't respond. ***
Received on Fri Jan 06 2006 - 13:11:44 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US