Hi,

Dmitry I understand your preocupation with such a scenario, however, I'm not
sure what you seem to wish is a feasable implementation for a database
server. I can't say how Oracle treats such things but take MS SQL Server
for example...

The system administrator (SA) has unlimited power in the system. He has
total control of HIS server. I don't know if people would like to have
databases in their servers over which they do not have control. This could
pose a problem for specially designed backup routines and maintnance
procedures ffor which the administrator would be totally dependant on a 3rd
party.

I know many people have wished for this kind of thing, when distributing
client/server applications which implement part of it's logic in triggers
and stored procedures. Perhaps an alternative could be the ability of the
owner of the object to have an option to specify at creation that it's
source script cannot be extracted (for SPs and triggers), after all, it is
the client's data that is in the database. He should have access to it, but
not necessarily to your logic.

Best regards,

Mauricio Longo

----- Original Message -----
From: "Dmitry Yemanov" <dimitr@...>
To: <IB-Architect@egroups.com>
Sent: Tuesday, January 09, 2001 5:47 AM
Subject: Re: [IB-Architect] Re: Nailing down the external file problem.


> Hi,
>
> > > The security database is probably not a good place to put things. It
> > is a well
> > > known weakness that a user who has access to the server in some way
> > can replace
> > > the security database with one of their own.
> >
> > This weakness must be addressed anyway. I hadn't thought about it
> > much: is the problem in the OS or Interbase (I know it exists on the
> > baby Windows and Novell systems)? I hadn't thought it a problem on a
> > properly configured secure system like NT or Unix.
>
> Cannot agree. Let us suppose I have a completely pre-configured solution
> and I don't want customers to have full access to the database. All
> administration tasks are performed through the software with the
hard-coded
> SYSDBA password or somehow else (for example, by engineers of our
company).
> But I cannot guarantee that there's no low-level changes made by the
> customer in the database, because of an ability of isc4.gdb to be
> potentially replaced. Maybe this example isn't the best one, but I hope
> you'll take the point.
>
> Best regards,
> Dmitry
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
>
>