Hi,

At March 3, 2004, 14:50, David Cornelius wrote:

> So far, I haven't run into a situation where I would need to
> prevent a user from gaining access to the database, but I can
> imagine a scenario where you're deploying a proprietary application
> that will be installed by the customer and you don't want them
> to see your data structure or code. Is it really true that
> there is no way to prevent that in Firebird?

I think this is part of the discussion in regards to the security for
FB 2.0. But, don't take my word for it.

> I suppose at least you
> can remove the source code from procedures and triggers--as
> discussed last month in this group.

That's pretty much what you can do. And, possibly encrypt some data
fields. But, if the application where most of the data is entered by
the user(referring to the buyer of the software), that data belongs to
the user and has every right to access that data which ever way he/she
wants. Unless, the user signed a contract limiting what he/she can do
with the data.

> Also discussed last month, was a trick to prevent SYSDBA from
> accessing a database by creating a SYSDBA role, but after reading
> that thread again, I'm left thinking that wouldn't stop a Firebird
> reinstallation any more than simply hiding the SYSDBA pass
> word.

The roles are stored within the database itself, not security.fdb. So
it might still work. Although I never tried it.

> I've done some work with another database, DBISAM
> (elevatesoft.com), which allows the tables themselves to be
> encrypted with a password.

If I'm not mistaken this has been talked about for FB 2.0, but I can
confirm at 60%.

> It would be nice to see something like
> this or possibly some other method of preventing a deployed database
> from prying eyes.

My comment about user data applies to this.

--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)