>
> Correct Ivan, in the end they can do whatever they want with it,

but

> the software I wrote which uses the DB connects using specific
> username/password, so if the change security Db, my software won't
> connect anymore.
> The problem isn't so much that there are any secrets in my db,

it's a

> matter of responsability when my system runs badly, because

they're

> messing arround in the production database. I'm just trying to

find a

> way that I can limit their privs, but I don't want to limit their
> maintenance abilities. Sure they can access a backup file and

restore

> it on another server, and play with it as much as they want, but

not

> the DB-file which is used in production.

I am affraid it is possible to grab the DB, mess with it and restore
the user settings so your app will function and you won't find the
difference other than the mishap in data and structure which can be
accused to be done by your app. Moreover if you DO such obstacles in
database access, it wil be harder to prove that somebody messed with
a database, as they wil claim that noone knows the sysdba password.

afaik firebird does nothing to protect your data if you allow users
to have file access to the database file or security database file :(

it is not only your problem, and I would like to ask again when will
crypto function be included in the firebird engine? The least that
could be done is locking the database changes with another layer of
password protection (something longer than 8 byte password please).

> Dirk Naudts.

CUIN Kaczy