At 11:59 PM 5/11/2009, you wrote:

>I have been using Firebird 2.1 for some time now (developing in Delphi 7). It is now time to start putting the system with customer's. So I want to add access control and passwords, etc.

Better late than never! ;-)

>It seems that this is not possible, and I am puzzled. Even MSAccess can do this.
>
>I know how to change the SYSDBA password (using GSEC, etc). I can and have done this ok.
>
>There are two problems with this - at least.
>
>1. This password is for ALL databases. So the password is for the server, not the databases.

Indeed. So don't deploy databases owned by SYSDBA that contain objects created by SYSDBA. This user has full destructive rights to everything.

>2. all someone has to do is copy a passworded database to another server - with a password that they know - and they are in! Seems rather pointless using passwords at all.

It doesn't seem like an effective security model to deploy a system in such a way that "someone" can get hold of it and copy it.

>From reading this forum, I see that the only real way to put any sort of access control is to use Roles. But if you login as SYSDBA, what is the point? Surely Roles are not relevant then?

Users are server-based. And, yeah, sure, gsec can be used to change the SYSDBA password but it's also the place where you add users and assign passwords for them. (Since you're using Delphi, it might be quite useful to look at the service components, if they are available for whatever interface you are using.)

Any user other than SYSDBA requires SQL permissions to access any object in a database. You use GRANT and REVOKE statements to assign permissions FOR objects TO (or FROM) users. Roles are recommended (but not required)
Roles are database-based. They are used to package SQL permissions so that the poor old SYSDBA (or owner) doesn't have a mountain of identical sets of permissions to maintain.

>If I have this all wrong, then please feel free to clear me up!

It seems a good time to read up on users and permissions. Give yourself time to get your head around how they work so you can (1) design your security scheme properly and (2) write some meaningful documentation about it for your customers' system administrators. Don't deploy your software with SYSDBA access hard-coded! Use login prompts. Give the SYSDBA password (which should be STRONG) to one responsible user, with documentation on how to change it and keep a secure record of it.

And, like Dmitry advises, take proper steps to secure the server and the filesystem.

./heLen