Re: [firebird-support] Understanding Firebird Security
Dimitry, > You cannot do that if you > 1) Have no access to the file (and server file system as whole). > 2) Don't know password of database owner. 1) Yes agreed, you need access to the file - so I have been testing what happens if the file does somehow fall into the wrong hands 2) In my testing I was able to open MyDB and view its contents without knowing the owner's password just by making it use my default security.fbd and SYSDBA/masterkey. Steve.
Re: [firebird-support] Understanding Firebird Security
Alexey, thank you for the extremenly quick response. So, I did understand correctly - anyone can open any Firebird database and view the data (unless it happens to be encrypted). I am rather shocked by that. Steve Bailey
[firebird-support] Understanding Firebird Security
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
Re: [firebird-support] Firebird 4 and RDB$ERROR
Helen, Thanks for the prompt reply. You wrote: "So - off-topic in Firebird Support. But, anyway..." Apologies for that. I did not read the welcome email (which says no questions on alpha or beta releases) until after I had posted my question (assuming Firebird Support was the right group). Maybe this question is also off-topic, but can you tell me which group I should use for posting questions about FB4 Beta 1? Steve.
[firebird-support] Firebird 4 and RDB$ERROR
I am using Firebird 4.0 Beta 1. The release notes describe a new system function RDB$ERROR: "The function RDB$ERROR() takes a PSQL error context as input and returns the specific context of the active exception. Its scope is confined to the context of the exception-handling block in PSQL. Outside the exception handling block, RDB$ERROR always returns NULL" To test this in iSQL I have tried: select rdb$error(gdscode) from rdb$database This results in: Statement failed, SQLSTATE = 42000 Dynamic SQL Error -SQL error code = -104 -Token unknown -GDSCODE I was expecting NULL to be returned. Have I misunderstood?
