Given the short term choice of making gsec work or implementing
create/alter/drop/upgrade user in Vulcan, I've chosen the latter. This
has forced me to think (and prototype) in some detail concerning
security plugins, which I'll describe later in a different post. But
that, in turn, has forced me to think a little more about the
relationship between a database engine and the security database.

I think everyone understands how bad the existing mechanism is. The
security database has a magic name, has a special database parameter
block (dpb) item to identify a authentication logon, uses a formerly
magic account and password, but really does some internal handle address
hackery to determine whether or not a given attachment is a bona fide
authentication request. This strategy is basically a crock, violating
our own architecture in assuming semantics associated with handle
addresses rather than just handle, puts unreasonable constraints on the
Y-valve, and makes it difficult or impossible to perform rolling
upgrades for major versions with incompatible ODSes.

We need something better.

I think a possible solution is a "user information" call looking like:

ISC_STATUS fb_user_info (ISC_STATUS *statusVector,
DbHandle
*databaseHandle,
int dpbLength,
const UCHAR *dpb,
int itemsLength,
const UCHAR *items,
int bufferLength,
UCHAR *buffer)

The call would use the dpb to identify user name, password, ip address,
or other potential authentication information and attempt to
authenticate the user. If successful, it would return the requested user
information. If the authentication failed, it would either return an
error or a "no available information" item (vote for one). The dpb
provided, presumably, would be the dpb used to attach to a client
database (as opposed to the security database).

Among the nice things about this is that a security database need have
any magic associated with it. It could have an almost useless account
advertised in a configuration file with no access to any table,
restricted, practically, to validation requests. The mechanism is open
ended, allowing extension to support additional authentication and user
attributes. It would work LAN or network wide and work across major
engine versions. It could be armored to detect, report, and shutdown
probes. It would also allow authentication without exposing the user
list or hashed passwords. User information would otherwise require a
valid access account to the security database itself.