Alex Peshkov wrote:

>>
>> On a different topic, we need to decide what to do about the USERS
>> table. In Firebird, this table is present only in the security
>> database. In Vulcan, it can be in any table with a security database
>> of "self". I do think we should change the table name to RDB$USERS
>> and add the RDB$ prefix to the field names. Or should we use FB$?
>> Sooner or later we should recognize that RDB interoperability is no
>> longer a major priority.
>>
>> Among the options to make the transition:
>>
>> 4. Go cold turkey and forget that the table USERS ever existed?
>> 5. Add RDB$USERS to the set of system tables automatically created at
>> database creation time whether it is needed or not.
>> 6. All of the above
>> 7. None of the above
>>
>> I think Firebird 2 and Vulcan need a coordinated strategy on this
>> one. Perhaps #5 is the path of least resistence even though it does
>> define an unnecessary table in non-security databases.
>>
>
> At first I should agree that Firebird 2 and Vulcan need coordinated
> strategy at this. Let me first refresh others memory abour fb2 cituation.
>
> To begin with, fb2 doesn't have table USERS at all. Instead it has
> table USERS_BG (BG is 'background'), having almost same structure, as
> old table USERS. Except field PASSWORD, which has 64 bytes width, not 32.

Here are what I think are the strategic questions:

1. How is RDB$USERS created?
2. How is RDB$USERS backed up and restored?
3. Is there a "core" definition of RDB$USERS, and if so, what is it?

The security plugin architecture should drive the answers. For a quick
recap, a security plugin in a loadable module to manage, among other
things, user identities and authentication. A security plugin has two
methods to support these functions. The method updateAccountInfo takes
a authentication parameter block (apb) describing an action (create,
alter, drop) to be taken for a designated user. The other method,
authenticateUser, takes a database parameter block (dpb), a set of
requested user information items, and an output buffer. If the security
plugin is able to authenticate the user described in the dpb, it returns
the information requested about that user. Otherwise it throws an
error. In this architecture, any tables required for authentication are
owned by the security plugin, not the core engine.

The first Vulcan version has a single, builtin security plugin that
emulates, as a subset, the Firebird 2 authentication semantics. For
compatibility (sanity and common sense), Vulcan and Firebird 2 should
use the same RDB$USERS table description. I'm perfectly happy to take
the Firebird 2 users table, rename it RDB$USERS, sprinkling around the
prefix RDB$, and live with it.

That said, I don't think that RDB$USERS should, per se, be cast as part
of the security architecture. Other plugs may want different table
definitions or no table at all.

I'm inclined to think that the best way to handle RDB$USERS is to create
it on demand (first call to updateAccountInfo), marking it as a
non-engine system table (we'll assign a RDB$SYSTEM_FLAGS value dedicated
to security plugins). GBak can back it up and restore it like any other
non-engine system table.

Still outstanding is the need for a mechanism to fetch a list of users
and attributes that works for an external security database, internal
authentication, and arbitrary security plugins. A pseudo-table (i.e.
canned result sets) would do it, but we really don't have the mechanisms
in place to handle pseudo tables. Perhaps the info mechanism could be
used? [I'm not trying to solve this problem for this version of Vulcan.]