I propose that we add the following commands to Firebird SQL beginning
with 2.0 (if possible):

create user <username> [set] password <quoted string>
alter user <username> [[set] password <quoted string>]
drop user <username>

We will want to extend the set of options beyond password when we
implement security plugins, but that can wait until them.

I also propose an extension to the API to perform similar functions.
The call is:

ISC_STATUS ISC_EXPORT fb_update_account_info (ISC_STATUS* userStatus,
isc_db_handle *dbHandle,
USHORT apbLength,
UCHAR *apb);

where the account parameter block parameters and options are:

/*********************************/
/* Account parameter block stuff */
/*********************************/

#define fb_apb_version1 1
#define fb_apb_uid 2 // user id
#define fb_apb_gid 3 // group id
#define fb_apb_protocol 4
#define fb_apb_account 5
#define fb_apb_password 6
#define fb_apb_group 7
#define fb_apb_first_name 8
#define fb_apb_middle_name 9
#define fb_apb_last_name 10
#define fb_apb_dba_account 11
#define fb_apb_dba_password 12
#define fb_apb_operation 13

// Account maintenance operations

#define fb_apb_create_account 1
#define fb_apb_update_account 2
#define fb_apb_delete_account 3

Next, I propose that the API entrypoints

isc_add_user
isc_modify_user
isc_delete_user

be deprecated (the entrypoints maintained but mapped into
fb_update_account_info.

Finally, I propose a database parameter block option "fb_dpb_ip_path" be
defined with the following format:

fb_dpb_ip_path <total length> <count byte> <ip address list>

where "ip_address_list" is an ordered list of ip addresses, each
expressed as 4 byte binary integer in "vax" format. The fb_dpb_ip_path
parameter would be created and managed by the remote server component,
ordered by by reverse distance from the server, i.e. closed connection
first. The remote server would either append the parameter to a given
dpb without a fb_dpb_ip_path parameter, or rewrite a dpb with an
fb_dpb_ip_path parameter so that it's client's ip address would appear
as the first ip address. [Note: only the first ip address can be
consider reliable for security purposes.]

I recommend that the user management SQL commands and
fb_update_acount_info be implemented in Firebird 2.0, with
fb_dpb_ip_path be deferred to Firebird 3.0.

The rationale for these proposals are:

1. SQL commands are the natural mechanisms to manager user accounts.
2. Security plugins require a greater degree of abstraction than
available in the current design.
3. The existing account API (isc_add_user, et al) utilizes a fixed
data structure (USER_SEC_DATA) that is not extensible without
extending all transmission layers.
4. Gsec is an abomination that demands deprecation.
5. The security database model is scheduled to be downgrade from a
core feature to one of a set of security options in V3, so
dependencies on the security database should be phased out sooner
rather than later.
6. Connection IP information will be necessary for some security plugins.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376



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