Subject Re: [Firebird-Architect] Create User Proposal
Author Dmitry Yemanov
"Jim Starkey" <jas@...> wrote:

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

I think it's 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.

Please read my message in fb-devel. I think it's good to distinguish between
database users and external logins (auth ids) and store users (only) inside
the database along with the external auth id mapping. In this case the
proposed DDL statements are implemented in the more natural way.

> 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);

No objections.

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

Agreed.

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

I'm not sure I understand why we need a list. Do you have a multi-hop
ability in mind or anything else?

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

Agreed.


Dmitry