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?