dbagregc wrote:

> I work for a software company who uses Firebird in our application.
> We have customers who pay "consultants" to set them up with our
> software and do custom work sometimes. One thing many of
> these "consultants" like to do is put data in to our database
> outside of the means we provide them. This almost always leads to an
> eventual support call from the customer saying that our program is
> not working and its our fault, whereas in actuality it is most
> likely their "consultant's" fault for putting in bad data because
> they thought they knew what they were doing.
>
> Ideally we would like to change the SYSDBA password and create a
> user for them to "look but not touch" and a user for the program
> with full access. But it appears that the whole password system in
> Firebird is part of the Firebird server. I changed the password (as
> far as I know, correctly) which worked fine but this is a server
> wide password so for our users that have 2 programs using Firebird
> this will not work because their other piece of software will not
> function. Plus if I move the database to another computer the
> password does not move with it. This would allow a consultant to
> move the database to another computer to do editing then move back
> when they are done which helps out our cause none.
>
> We are trying to protect the users from themselves essentially. If
> it is at all possible and fairly easy to figure out these
> unscrupulous "consultants" will find any and every way to get in our
> database and do with it as they please. This is totally
> unsupportable with a database of over 500 tables. Is there a way to
> give a database its own unique password and lock down the data so
> that no one can have write access to the data other than our program
> without affecting other vendors software? If not do you guys have
> any other suggestions, because we DESPERATELY NEED INTEGRITY!

I have seen systems that use a database merely as storage. Constraints,
keys, triggers and so forth are disregarded and all logics are put into
the webserver or client. This is positively sad. I *guess* that you are
burdened with such a legacy design.

What I did once in this case was rewrite the entire system. If that is
not an option then I would *not* try to do strange things with FB
functionality. Any oddities performed on the security database is likely
to fire back at you, especially when new versions of FB comes.

An idea is to do some selects upon application startup on those
particular areas of information that has a negative impact on the
business logic coded into client or middleware. That might be both
certain rows or certain columns in some tables. Then either compare this
to constants or calculate some kind of hash/CRC. If there is an mismatch
- throw up a dialog saying that the database has been tampered with in
an unsupported manner. You could catch your consultants early in the
process of raising havoc.

Regards,

/Dany