Re: [holger: Re: Logger for libgda]

[David Marín Carreño <davefx bigfoot com>]

On Tue, 28 Nov 2000, Holger Thon wrote:

> 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.

Always (at least in PostgreSQL) we can close all remote connections to the
database server, only allowing local connections, and using a gda-provider
locally installed as the only access method to the database.

> 
> > > > > 
> > > > > 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... :-)
> 

Crackers are evil hackers... :-) If we close remote connections in the
DBM, no one will be able to do such nasty things... unless he/she can
log in to the server...


> > > 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).
> 
> ...
>
> 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.
> 

The log and the logger must live in the server. And there must be only one
log/logger for all clients.

> 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
> 

-- 
David Marín Carreño <davefx bigfoot com>   mmmm
(aka DaveFX)   ICQ UIN: 34866516            ""MM    Mm
http://www.bigfoot.com/~davefx       mmmm     mMM    MM
                                   mM"""MM    MM    mMM
ASPL Fact official developer             "M   "   mM""
http://aspl-fact.sourceforge.net             mmmm  
                                           mM"""MM         
Advanced Software Production Line SL             "M