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>'".

Here is an updated version of the RDB$USERS tables implemented by Vulcan:

static const char *creationDDL [] =
{
"create domain rdb$user_name varchar(128) CHARACTER SET
UNICODE_FSS;",
"create domain rdb$uid integer;",
"create domain rdb$gid integer;",
"create domain rdb$password varchar(64) CHARACTER SET ASCII;",
"create domain rdb$user_privilege integer;",
"create domain rdb$comment BLOB sub_type TEXT segment size 80
CHARACTER SET UNICODE_FSS;",
"create domain rdb$name_part varchar(128) CHARACTER SET
UNICODE_FSS;",

"create table rdb$users(\n"
"rdb$user_name rdb$user_name not null primary key,\n"
"rdb$sys_user_name rdb$user_name,\n"
"rdb$group_name rdb$user_name,\n"
"rdb$uid rdb$uid,\n"
"rdb$gid rdb$gid,\n"
"rdb$password rdb$password,\n"
"rdb$privilege rdb$user_privilege,\n"
"rdb$comment rdb$comment,\n"
"rdb$first_name rdb$name_part,\n"
"rdb$middle_name rdb$name_part,\n"
"rdb$last_name rdb$name_part);",

NULL
};

If there are any more additions or corrections, please let me know
sooner rather than later.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376