Rather than respond individual to so many interest posts, let me batch
some comments.

First, I'd like to ammend my proposal with the addition of

upgrade user <username> ...

The "upgrade user" command is syntactically parallel to "create user",
and is semantically equivalent to "alter user" if the named user exists
and semantically equivalent to "create user" if not. The upgrade form
allows a single script to both create and update accounts.

Dmitry proposed handling a user like other database objects and to
separate "user name" used in the DDL command and an "identified by"
string for logon purposes.

Other database objects (tables, fields, triggers) are defined in core
system tables. It seems obvious that users/accounts should be handled
this way. There seems broad consensus that authentication should
delegated to a security plugin, and different security plugins will have
different ideas of what should be stored in a system table. We could
define a core system table FB$USERS (folks, we're not rdb anymore) with
account name as primary key. All other fields would necessarily be
defined by whatever security plugin was configured. Defining a system
table with one known field and an unknown number of other fields just
doesn't feel satisfying. If someone could come up with a scheme that
was both useful and open-ended, I could be convinced otherwise, but for
now, an architecturally specified table to hold user data doesn't seem
worth the effort, particularly when the legacy form of authentication
doesn't handle database specific account information at all.

I think I understand the motivation for separating user name and user
indentification, but I don't think it's a good idea. It could be
marginally useful, but it also be a source of endless confusion over
which attributes, name or identification, was used in which context.
For simplicity, which has virtual, let's stick with a single identifier
for a database user. That said, there is merit to record on user
information like full name, fax number, and mother's maiden name. Not
all security models will want to track this stuff, but the
fb_update_account_info mechanism should be able to accomodate it
providing we can successfully manage the APB attribute space...

For the purpose of discussion, I envision the set of security plugs
would include:

1. Central security database for backwards compatibility (and
somebody even might like it)
2. User/passwords stored in target database
3. PAM based for *ix systems
4. NT Domain based for Windows systems
5. LDAP based for large organizations

There will probably be more, but there won't be any fewer.

Someone raised the question as to why the network connection database
parameter provided for a list of addresses. I did this because
Interbase/Firebird/Vulcan TCP servers can redirect a connection across
the network. I want to security plugin to have this information. In
general, only the last (first in order) address is reliable (subject to
Nickolay's final approval, of course), but if other addresses can be
identified as trustworthy, the chain has some value. In any case,
however, the other identification dpb parameters all provide lists of
transmission agents by version, type, and product. For what it's worth,
Interbase supposed TCP, DECnet, Apollo ring, and transciently,
Jim's-really-crappy-asynchronous-line-protocol. Interbase servers were
used as inter-network gateways all the time.

The database handle in fd_update_account_info is the target the
database. The security database is the business of a future plugin and,
in general, inaccessible.

The fact that SHA (and MD5) may have collisions is irrelevent for
password hashing. The question is not whether collisions are possible,
but whether you can compute a "collision" given a hash.

Alex has proposed an spb parameter to specify security database for
gsec. This is a very bad idea. Security configuration data should
reside solely in a write protected file. Moving this stuff to a utility
compounds mistakes made in the past.

Alex has also suggested that fb_update_account_info need not be thread
safe. This is incorrect. The entire API must be thread safe. All
security plugins themselves must also be thread safe. No component,
whether Y-valve, remote interface, engine, or gateway, presumes to
manage threading for any other component. Every component is
responsible for it's own thread safety.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376



[Non-text portions of this message have been removed]