Subject Understanding Firebird Security
Author

I am new to Firebird, trying to understand how it handles user security.


I want to create a database owned by and accessible to only one user - and that should not be SYSDBA.


Let's call the database MyDB.


In databases.conf I created an alias for MyDB and specified that it should be its own security database.


With the Firebird server NOT running, I did the following in iSQL:

 - connected to the sample employee database (which uses the standard security3.fdb database) as SYSDBA

 - created a new user called MyNewUser and set a password

 - quit iSQL and restarted it as user MyNewUser

 - created MyDB.fdb in the folder already specified for it in databases.conf (so MyNewUser is the owner of MyDB)

 - connected to MyDB as user MyNewUser

 - created a test table and inserted a few test records.

 

Next I started the Firebird server and using a Firebird client (IBExpert) I did this:

 - attempted to connect to MyDB as user MyNewUser - this was successful

 - attempted to connect to MyDB as SYSDBA - this was unsuccessful, which is what I was expecting.

 

Next I edited the databases.conf alias for MyDB and removed the SecurityDatabase entry so it would now use the standard security3 database.


Now when I attempt to connect as SYSDBA it is successful and I can see the test records that I previously entered.


This is the point where I confess to being confused. I presume I am wrong but it looks like any Firebird database has a "public back door". What stops me taking a copy of SecretDatabase.fdb and connecting to it on my own Firebird installation?


Steve Bailey