Subject | Understanding Firebird Security |
---|---|
Author | |
Post date | 2019-05-20T10:19:19Z |
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