Subject | Re: [firebird-support] Firebird sysdba account |
---|---|
Author | Niben M Singh |
Post date | 2008-08-14T17:17:16Z |
So that means, like Thomas had said
"Pretty simple, don't use SYSDBA as owner for deployment!! !"
will not work.
When you deploy your application with Firebird database, no matter whether you create database with owner other than SYSDBA, one can still copy the FDB file into different server and use SYSDBA to access the database. Seems like there is not way to protect the schema and data using Firebird security in this case. It will need to handled by OS security or encrypting the disk volume itself.
Data Enryption is not an option as it will not protect schema and will not allow sub string comparisons....and so forth.
Are there any other ways??
"Pretty simple, don't use SYSDBA as owner for deployment!! !"
will not work.
When you deploy your application with Firebird database, no matter whether you create database with owner other than SYSDBA, one can still copy the FDB file into different server and use SYSDBA to access the database. Seems like there is not way to protect the schema and data using Firebird security in this case. It will need to handled by OS security or encrypting the disk volume itself.
Data Enryption is not an option as it will not protect schema and will not allow sub string comparisons....and so forth.
Are there any other ways??
--- On Thu, 8/14/08, Helen Borrie <helebor@...> wrote:
From: Helen Borrie <helebor@...>
Subject: Re: [firebird-support] Firebird sysdba account
To: firebird-support@yahoogroups.com
Date: Thursday, August 14, 2008, 9:50 AM
At 23:13 14/08/2008, you wrote:
>This is what I have tried.
>
>1. Created new user/password using gsec.
>2. Created new database using the new user as the owner.
>
>But, I can still connect to this new database using SYSDBA/masterkey credential. Am I missing anything?
Yes, you've missed the point that SYSDBA has full destructive rights to ALL databases on the server. The Owner has similar rights only to the database it owns (but it can't operate on the security database: only SYSDBA can do that.)
And you might also have missed the point that the database owner doesn't have any privileges to any objects that were created by another user, including SYSDBA - SO MAKE SURE YOU LOG IN AS OWNER WHEN YOU CREATE OR ALTER OBJECTS !!
./heLen
[Non-text portions of this message have been removed]