Surrogate user properties (UNIX, Linux)

Use the ACCESS TO PROPERTIES clause of the GRANT statement to map users to surrogate user properties required for access to HCL OneDB™ resources.

Note:

Only a DBSA can map externally authenticated users to valid surrogate user properties. If the USERMAPPING configuration parameter is set to enable support for mapped users, a DBSA issues the GRANT ACCESS TO PROPERTIES statement to map users to properties that correspond to the appropriate level of authorization.

Mapped users can connect to HCL OneDB with the surrogate user properties if they authenticate with a pluggable authentication module (PAM) or single sign-on (SSO).

Mapped users can connect to HCL OneDB with the surrogate user properties if they authenticate with a pluggable authentication module (PAM).

ACCESS TO PROPERTIES Clause

Notes:

¹ Use this path no more than 16 times


Element	Description	Restrictions	Syntax
directory	Path name of directory where user files are stored.	Length cannot exceed 255 bytes, and must conform to the rules of your operating system. The directory must also: Belong to the mapped user_ID and group_ID Have read, write, and execute permissions for the owner Not have PUBLIC write permissions	Quoted String
group_ID	Group identifier number to which you want to map user. The list of `group_id` value or values that you specify must be enclosed in parentheses. .	The group_ID cannot be: A group ID with server administrative privileges (DBSA, DBSSO, AAO, and BARGROUP) Group 0 (root, sometimes referred to as wheel or system) A group ID associated with group bin or group sys The group ID must be present in /etc/onedb/allowed.surrogates file.	Literal Number
group_name	Name of an existing operating system group having the permissions to which you want to map user . The list of `group_name` values must be enclosed in parentheses.	Length cannot exceed 32 bytes. The group name must be present in /etc/onedb/allowed.surrogates file.	Owner name
privilege	Administrative privilege to assign user. Valid values are as follows: DBSA DBSSO AAO BARGROUP The `privilege` value or values must be enclosed in parentheses.	The USERMAPPING configuration parameter must be set to ADMIN to grant server administrative privileges with the AUTHORIZATION keyword.	Quoted String
user	Authorization identifier of a specific user that you are mapping to user properties.	Must be an authenticated authorization identifier	Owner name
user_ID	User identifier number to which you want to map user.	user_ID cannot be the one that belongs to user root or user informix. The user ID must be present in /etc/onedb/allowed.surrogates file.	Literal Number
OS_user_name	Name of an existing OS user account on the HCL OneDB host computer having the permissions to which you want to map user.	Must conform to the rules of your operating system . The user name must be present in /etc/onedb/allowed.surrogates file.	Owner name

Usage

The best practice is to map user to a specific OS user name that is reserved as a surrogate user identity only. You can add groups associated with the surrogate user identity with the GROUP keyword, and change the home directory with the HOME keyword. If the operating system administrator has specified acceptable surrogates in the /etc/onedb/allowed.surrogates file, you can only map users to those specified OS users or groups.

If you map user to a user ID number, then remember to not create a user account on the HCL OneDB host computer with the same number.

The USERMAPPING configuration parameter must be set to ADMIN in order to assign user a server administrative privilege with the ADMINISTRATOR keyword.

Note:

Use of this AUTHORIZATION clause (and of the AUTHORIZATION clause of the ALTER USER, CREATE USER, or CREATE DEFAULT USER statements) is not recommended. Different syntax will support role separation in a future release.

The PUBLIC and AUTHORIZATION keywords cannot be used together in the same statement, because the PUBLIC group cannot be granted server administrator privileges.

Specifying a directory for the user files with the HOME keyword is optional, but in some cases it is highly recommended. When an externally authenticated user is mapped to a surrogate user name but no HOME directory is specified in the GRANT ACCESS TO statement, then the mapped user has the same home directory as the user account on the HCL OneDB host computer. When a user is mapped to a surrogate user identity with no set home directory, then HCL OneDB creates a directory for user files in $ONEDB_HOME/users. In the latter case, the directory name in $ONEDB_HOME/users takes the form uid.ID_number (for example, uid.101).

Examples

The syntax and explanations in this section are examples for the following environment, where the acronym GID abbreviates group ID number, and the acronym UID abbreviates user ID number:

There is a user fred with an OS account on the HCL OneDB host computer. User fred has database server access with UID 3000, GID 3000 (users), auxiliary group 200 (staff), and home directory /home/fred.
On the same computer, there exists an OS account for user dbuser. This account is locked so that dbuser cannot log in. The dbuser account exists only for the purpose of surrogate user mapping. It has UID 3050, GID 4000 (ifx_user), and home directory /home/dbuser.
The group ifx_user has GID 4000, with users bill and eileen.
The administrator setting up mapped users knows that there is no entry for UID 101 in /etc/passwd (or its equivalent) and no entry for GID 10011 or 10101 in /etc/group (or its equivalent) .
User bob does not have OS account on the HCL OneDB host computer but can authenticate through PAM or LDAP. The database server is configured to accept authentication through the PAM or LDAP module.
The USERMAPPING parameter in the onconfig file is set to ADMIN.

Mapping an externally authenticated user to a surrogate user name:

The administrator maps bob to the database server access privileges that already exist for user fred by issuing the following GRANT statement:

GRANT ACCESS TO bob PROPERTIES USER fred;

Granting HCL OneDB access to all externally authenticated users:

In this environment, the purpose of the user dbuser account on the HCL OneDB host computer is to grant database server access to mapped users. In a situation where there are many mapped users and they do not need to know about the user files created in the home directory, the administrator might find it efficient and sufficiently secure to map PUBLIC to the dbuser surrogate user identity. The administrator can map all authenticated users (PUBLIC) to the privileges established for dbuser with the following GRANT ACCESS statement:

GRANT ACCESS TO PUBLIC PROPERTIES USER dbuser;

Note: The mapping of PUBLIC to a surrogate user identity is designed for mapped users who do not create or are not concerned with user files on the home directory, such as a consumer who is accessing HCL OneDB databases on a retail Web site. If you want to map users concerned with the functioning of the database server to a surrogate user identity like dbuser, it is recommended to map these users individually with a designated home directory, as in the following example:

GRANT ACCESS TO bob PROPERTIES USER dbuser HOME "/home/dbuser/bob";

Mapping an externally authenticated user to a UID-GID pair:

The administrator maps bob to a surrogate user identity that consists of a UID-GID pair that enables database server access by running the following statement:

GRANT ACCESS TO bob PROPERTIES UID 101, GROUP (10011);

Because no specific directory was specified, a directory under $ONEDB_HOME/users will be created with the name uid.101 and this path will be used as the home directory. The UID 101 and GROUP (10011) are anonymous because they do not have entries in the respective /etc directories that designate UIDs and GIDs that can access HCL OneDB .

Alternatively, the administrator can map bob to a surrogate user identity that is a combination of an anonymous UID and to an explicit group, such as in the following example:

GRANT ACCESS TO bob PROPERTIES 101, GROUP (ifx_user);

Because the ifx_user group has members bill and eileen, the group is not anonymous.

Mapping an externally authenticated user to a surrogate user identity that has server administrative privileges:

In the following example, the administrator grants DBSA privileges to bob:

GRANT
ACCESS TO bob PROPERTIES USER fred, GROUP (ifx_user), AUTHORIZATION
(dbsa);

User bob is assigned UID 3000 (fred) and GIDs 3000 (users), 200 (staff), and the extra group 1000 (ifx_user). The administrative role granted to bob could be different by replacing dbsa with a different privilege (DBSSO, AAO, or BARGROUP). If the USERMAPPING parameter were set to BASIC in the onconfig file, then bob would not be granted DBSA privileges by this statement. If USERMAPPING were set to OFF, then bob would not be able to connect to the database server at all.

Examples

The following GRANT statements are examples of valid ACCESS TO PROPERTIES clauses, using hypothetical values. These examples do not represent the entire syntax and possible semantics of the ACCESS TO PROPERTIES clause.

GRANT ACCESS TO bob PROPERTIES USER fred;
GRANT ACCESS TO PUBLIC PROPERTIES USER dbuser;
GRANT ACCESS TO bob PROPERTIES USER dbuser HOME "/home/dbuser/bob";
GRANT ACCESS TO bob PROPERTIES UID 101, GROUP (10011);
GRANT ACCESS TO bob PROPERTIES 101, GROUP (ifx_user);
GRANT ACCESS TO bob PROPERTIES USER fred, GROUP (ifx_user), AUTHORIZATION (DBSA);