Alex Peshkov wrote:

>Jim Starkey wrote:
>
>
>>A detail left dangling is how the authentication table RDB$USERS gets
>>created by the default security plugin, SecurityDb. After running
>>around various rathole, I think the following makes sense:
>>
>> 1. SecurityDb creates RDB$USERS on the first call to
>> fb_update_account_info.
>> 2. If RDB$USERS does not exist, fb_authenticate_user return success
>>
>>This means that any database with a security database of "self" (which
>>includes the security database itself) has no password protection until
>>either a successful fb_update_account_info is executed or the table
>>RDB$USERS is created by some other process. In most cases, the table
>>will be created and populated by gbak.
>>
>>Among other things, this should simplify the installation procedure
>>which needs only to create an empty security database then execute a
>>"create user SYSDBA password '<whatever>'".
>>
>>
>>
>
>What happens, if old isc4.gdb or security.fdb (both same format,
>containing table USERS) is used as security database in vulcan?
>
>
>

The SecurityDb plugin ignores everything but RDB$USERS. An enterprising
developer might, if he wished, write a single ISQL SQL command to copy
from one to the other. If Firebird supported the REPLACE verb, the same
script could be used to update RDB$USERS as well. It would be better,
of course, if Firebird 2.0 were to adopt RDB$USERS as well, but that's
asking a lot, really. The issue with isc4.gdb is moot since Interbase
and pre-Firebird 1.5 don't handle fb_authenticate_users, but then
neither does Firebird 2.0. Oh, well.