"Jim Starkey" <jas@...> wrote:

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

We already have RECREATE and CREATE OR ALTER statements. AFAIU, the latter
one is exactly your UPGRADE statement, but it doesn't introduce additional
reserved words. Let's be consistent with the existing DDL.

And also getting back to the proposed [SET PASSWORD <pwd>] syntax element.
Some auth methods (e.g. biometrical) doesn't have a password at all. Some
other methods may have more complicated private auth data. So it seems that
SET PASSWORD is not universal. Even if we drop my idea of having FB$USERS
inside a database, maybe the suggested IDENTIFIED BY <tagged_string> (or
alike) syntax is more appropriate for any possible auth method?

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

It may also contain at least DEFAULT_ROLE. If the user credentials (not
directly related to authentication, like last/first names) are not subject
of auth plugin, then FB$USERS may also contain these columns.

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

Blob?

In fact, the only issue I see with the proposed scheme is a replication
between server-wide and database-wide user names. And I agree this is quite
serious issue, especially for read-only databases. I'll get back to this
question after more thinking over the weekend.

> 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

Tend to agree here.

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

Understood. But did you actually try this? Borland has broken this (known as
"multi-hop") ability when introducing dialects in IB 6.0 and it didn't work
since that time. I've fixed it in HEAD a couple of weeks ago, but the
solution requires some testing.


Dmitry