Subject | Re: Re: [firebird-support] Firebird 2.0 Security |
---|---|
Author | Helen Borrie |
Post date | 2007-01-16T21:11:37Z |
At 07:16 AM 17/01/2007, you wrote:
created during the build of the server software. The SYSDBA user has
full destructive rights to any database that the server is
controlling. You're not meant to retain the default password for
SYSDBA and you're not meant to create databases as the SYSDBA user, either.
If you are deploying a system, you can deploy a security2.fdb that
you have populated for use with your system and make provision in
your installer to overwrite the customer's security2.fdb. That is
likely to guarantee you a free ticket to a distant place if the
customer already has other applications that use Firebird.
You will need to have created SQL privileges for specific users to
access specific objects. These you will have already set up in the
database[s] that you deploy. The users don't have to exist in
security2.fdb at the time you define the database privileges, btw...
The right thing (and the only thing to do if there's a chance you are
deploying to a site that already has Fb installed) is to include a
mechanism to add the needed users to security2.fdb at the end of your
installation routine. There are various ways to do this, e.g. a
routine that runs gsec, but any mechanism will need SYSDBA access to do it.
./heLen
>During Firebird installation a Security2.fdb is created with theNot clear what you mean by "created in code". Security2.fdb is
>default UID:SYSDBA and PWD:masterkey.
>
>My question is can a Security2.fdb be created in code with different
>defaults ie UID:Admin PWD:Pass?
created during the build of the server software. The SYSDBA user has
full destructive rights to any database that the server is
controlling. You're not meant to retain the default password for
SYSDBA and you're not meant to create databases as the SYSDBA user, either.
If you are deploying a system, you can deploy a security2.fdb that
you have populated for use with your system and make provision in
your installer to overwrite the customer's security2.fdb. That is
likely to guarantee you a free ticket to a distant place if the
customer already has other applications that use Firebird.
You will need to have created SQL privileges for specific users to
access specific objects. These you will have already set up in the
database[s] that you deploy. The users don't have to exist in
security2.fdb at the time you define the database privileges, btw...
The right thing (and the only thing to do if there's a chance you are
deploying to a site that already has Fb installed) is to include a
mechanism to add the needed users to security2.fdb at the end of your
installation routine. There are various ways to do this, e.g. a
routine that runs gsec, but any mechanism will need SYSDBA access to do it.
./heLen