Thomas -

Thanks for the clarification! At least the other user wont have access to data, which is better than having everything exposed. It will be better to protect the schema too, somehow..someday.

I also saw that any other user, other than database owner or SYSDBA, who logs into the database succesfully have read permission to RDB$ROLES table. So if use the SQL as you suggested

INSERT INTO RDB$ROLES

(RDB$ROLE_NAME, RDB$OWNER_NAME)

VALUES

('SYSDBA', <your connected owner>);

then they can see the owner name. The owner login can be created in the new Firebird server which can gain full access to the database.

So I did something like this


INSERT INTO RDB$ROLES


(RDB$ROLE_NAME, RDB$OWNER_NAME)


VALUES


('SYSDBA', 'XXXXX');


It seems to work but I hope there is no ramifications of doing this.

Please let me know if there is anything I should know.

Regards,
Niben

--- On Sun, 8/17/08, Thomas Steinmaurer <ts@...> wrote:
From: Thomas Steinmaurer <ts@...>
Subject: Re: [firebird-support] Firebird sysdba account
To: firebird-support@yahoogroups.com
Date: Sunday, August 17, 2008, 1:00 PM











> Thanks Thomas!

>

> I played with FB more as you suggested and now I am more confused (which I easily do), or may be I am missing something (which I often do :)).

>

> So here is what I tried -

>

> 1. Created new user in my FB server using GSEC.

> 2. Created brand new database using the new user, using ISQL.

> 3. Then I ran your ROLE query to give my new login SYSDBA role.

> 4. And, as you had said, it sure did lock SYSDBA user out. I could only connect to the database using my new user.

> 5. Then I created another user in the FB server and tried to connect to the database. Surprisingly, the another user was granted access to the database.

>

> Seems like even though we lock the SYSDBA out of the database as you mentioned. One can always copy the database into different server and create some other user, other than SYSDBA, and use that user to access the database.



Right, although, unlike SYSDBA, other users don't have access to tables,

... if they didn't get the SQL privileges granted. They can create new

objects like tables, views, ... though.



With Firebird 2.1, you could create an ON CONNECT trigger which throws

an exception if the connected user is different to a string literal.



But again, AFAIK with isql you can connect to the database suppressing

database triggers.



There is no ultimate solution yet. Things might get better if Firebird

support some kind of embedded authentication storing user/password

inside the database.



--

Best Regards,

Thomas Steinmaurer

LogManager Series - Logging/Auditing Suites supporting

InterBase, Firebird, Advantage Database, MS SQL Server and

NexusDB V2

Upscene Productions

http://www.upscene. com

My blog:

http://blog. upscene.com/ thomas/



























[Non-text portions of this message have been removed]