| Subject | Re: [firebird-support] How to create user with SYSDBA rights |
|---|---|
| Author | Helen Borrie |
| Post date | 2010-05-15T22:39:17Z |
At 11:04 PM 15/05/2010, you wrote:
Users (including SYSDBA) belong to the *server*, not to databases. Roles (like other SQL privileges) belong to an individual database: the server does not know anything about them. A role is a package of privileges that can be assigned to one or more users. In order to access the database objects granted via a role, a user must be specifically granted the right to that role. So just creating a new user (in the security database of a different server) won't give that user access to any role - including this role named SYSDBA.
The developer of this database has created the role 'SYSDBA' when deploying that database to *prevent* unauthorised users from accessing it. The developer knew that Firebird blocks the SYSDBA user if the database has a role of the same name. He wanted to keep the SYSDBA user out. Usually a developer will do this to try to prevent anyone from inspecting his metadata using applications other than his client application. You are experiencing the result of this protection.
SYSDBA is not blocked in the security database. You might be able to configure the server and in such a way that you can access the database as a network Administrator (or the root user on POSIX). I say "might" because I haven't used it to try to crack a database with this style of access blockage. Don't supply user name or password when logged in as a platform super user.
All that said...if you do have authority to inspect the database with external tools (and thus access metadata) then the obvious thing to do is ask the vendor for the credentials of a user that is authorised to the SYSDBA role. In that case, you will need that user name in your local security database, a password for it (your choice) AND to supply that user name, password and the SYSDBA role in the login parameters.
./heLen
>I have created a new user using GSEC. I want to assing the SYSDBA rights to this new user. How do I do that.Assuming you are still trying to crack this database that has a role named 'SYSDBA', let's get a few things clear
Users (including SYSDBA) belong to the *server*, not to databases. Roles (like other SQL privileges) belong to an individual database: the server does not know anything about them. A role is a package of privileges that can be assigned to one or more users. In order to access the database objects granted via a role, a user must be specifically granted the right to that role. So just creating a new user (in the security database of a different server) won't give that user access to any role - including this role named SYSDBA.
The developer of this database has created the role 'SYSDBA' when deploying that database to *prevent* unauthorised users from accessing it. The developer knew that Firebird blocks the SYSDBA user if the database has a role of the same name. He wanted to keep the SYSDBA user out. Usually a developer will do this to try to prevent anyone from inspecting his metadata using applications other than his client application. You are experiencing the result of this protection.
>I am using firebird version 2.1You don't say which sub-release or platform. Carefully read the release notes that were deployed with the server software (in the ..\docs directory). Search on keywords "authentication" and "security" and read all of the items found.
SYSDBA is not blocked in the security database. You might be able to configure the server and in such a way that you can access the database as a network Administrator (or the root user on POSIX). I say "might" because I haven't used it to try to crack a database with this style of access blockage. Don't supply user name or password when logged in as a platform super user.
All that said...if you do have authority to inspect the database with external tools (and thus access metadata) then the obvious thing to do is ask the vendor for the credentials of a user that is authorised to the SYSDBA role. In that case, you will need that user name in your local security database, a password for it (your choice) AND to supply that user name, password and the SYSDBA role in the login parameters.
./heLen