[holger: Re: Logger for libgda]

[Holger Thon <holger gidayu max uni-duisburg de>]

----- Forwarded message from Holger Thon <holger> -----

Date: Tue, 28 Nov 2000 20:58:26 +0100
From: Holger Thon <holger>
Subject: Re: Logger for libgda
To: gnome-db-list gnome-db org

Hi!

On Mon, Nov 27, 2000 at 11:01:54PM -0100, Rodrigo Moya wrote:
> 
> > > > 
> > > > If you put it in the server, the database will be more secure: nobody
> > > > could access to the database without logging (only if you can set the
> > > > logger to be activated forever).
The provider could be circumvented by a faked provider which is search-path of
the environment of the running oafd before the original one. So security is
not that a great argument, imho.

> > > > 
> > > > If you put the logger in the client-side, an evil hacker could program a
> > > > modified client, and access the database server without logging.
> > > > 
Please cracker, not hacker (as i read some mail with gnome-db hackers as
subject...) ;-) Apart from that (and stated above), the cracker could have it
more easier and simply use a client application not based on libgda... :-)

> > > I don't understand what you mean here. The logging stuff should be optional,
> > > so a client would call, for example:
> > > 
> > > gda_connection_enable_logger(Gda_Connection* cnc);
> > > 
> > > And what do you mean by accessing the database without logging?
> > 
> > A real secure system needs to log every data modification: the logger must
> > not be enabled/disabled in this case. It should be always enabled... 
The database's server log is the most reliable information in that case,
client based logs are always to be considered ADDITIONAL information (but
not reliable, secure, uncompromised information). However, i agree that
putting logging into the provider/gda-server would make it more harder for
people to circumvent client based logs (client meaning being libgda client).

> > 
> > If we want this behaviour, we must program the logger in the
> > server-side. The client mustn't be able to deactivate the logger...
> > 
...
> > For example: I am redefining a product for sale. I change the price, and
> > the name of the product... Oh! I changed the wrong product... Please,
> > undo... I press the undo button and...
> > 
> > * I look for my last action in "Log" table:
> > 
> > 1287 davefx  localhost 23:45:45 27/11/2000 Products 45 name="foo" 
> > 
> > log-ID  
> >       username  
> >                host       time      date        table_modified
> >                                                      modified_entry
> >                                                             action
> > 
> > OK. The last thing we did was setting a new name... So we seek the entries
> > where the user davefx changed the 45th entry of Products table...
> > 
> > Here they are:
> > 
> > 644  davefx   localhost  13:23:21  15/11/2000 Products  45  new 
> > 645  davefx   localhost  13:23:21  15/11/2000 Products  45  name="lulu" 
> > 646  davefx   localhost  13:23:21  15/11/2000 Products  45  price=20.0
> > 1286 davefx   localhost  23:44:34  27/11/2000 Products  45  price=32.05
> > 
> > 
> > As we can see, the last name for the 45th product was "lulu". So it's
> > done: the undoer saves "lulu" as name for 45th product.
> > 
> > The 1287th entrance to the log is marked as old. So we can make redoing
> > this way too.
> > 
> > 
> > Perhaps it is not an optimal way... but it should work.
> > 
Only if the first transaction you log is the first transaction you make. In
each other cases, you have n-1 undos and can only ! :-)

Anyway, you have to fetch the data a transaction attempts to modify 
from the server before applying that transaction, and log that data first.
This would be a great hint for avoiding collision of multiple transactions
from multiple systems:
 Client a modifies some data and commits transaction. After that, client b
 modifies the commited data (making it right again and applying some updates)
 and commits his transaction. Now client a issues an undo. Updates of client
 b would be lost, because they're not in the log of client a.

Hope this problems can be solved, because i think having multiple undo levels
on transactions is a great idea and a valuable feature for libgda!

Ciao,

  Holger
-- 
Operator excuse of the instant:
You did wha... oh _dear_....

----- End forwarded message -----

-- 
Operator excuse of the instant:
IRQ-problems with the Un-Interruptable-Power-Supply