Security model for the db2cm command

The db2cm command is the main interface into Db2® cluster services, and as such acts on both the cluster manager and shared file system cluster provided for the IBM® Db2 pureScale® Feature. The db2cm command options that are available to a user depend on the user's authority.

In terms of the security model for the db2cm command, there are 2 user groups, broken down by the type of tasks each user group is likely to perform:
  • System Administrator
  • Cluster Administrator
Some db2cm options can only be specified by the System Administrator. Other options can be specified only by the Cluster Administrator and/or users that are part of the Db2 SYSADM, SYSCTL, or SYSMAINT group, and a smaller subset of commands can be run by any user ID on the system.
Note: Note that all Db2 system and cluster administrative commands require DB2INSTANCE environment variable to be set.

System Administrator

The System Administrator role is an end user with access to a root-owned userid for the operating system.

Users in this group have no requirements to access data in the database; this is an administrative role used for:
  • Installation and configuration of the Db2 cluster services portion of Db2
  • Maintaining clustered instances in the cluster domain and maintaining the shared file system cluster

The System Administrator performs administrative tasks that affect Db2 cluster services as a whole across all clustered instances on all hosts in the cluster domain.

The System Administrator can perform maintenance-related tasks, such as putting the domain or specific hosts into maintenance mode, exiting maintenance mode, or verifying if the domain/hosts are in maintenance mode. This user can also perform advanced maintenance operations on the cluster domain. These operations include creating, deleting, starting, stopping, or repairing the domain, creating or deleting a quorum device, and adding, removing, starting, or stopping hosts. Lastly, this user can grant and revoke the Cluster Administrator privilege to a specified user.

Cluster Administrator

Users with Cluster Administrator privilege are able to use the db2cm command to keep the instance up and running, and to perform some administrative tasks on the cluster manager, after the cluster domain has been created.

Users with Cluster Administrator privilege can perform various operations relating to the cluster resources. These operations include creating, deleting, listing, enabling, and disabling resources, and repairing and verifying the cluster manager resource model. Users can also import a past/current cluster manager resource model or export a current cluster manager resource model based on the existing cluster host configuration.

Note: System Administrator user can perform Cluster Administrator tasks that do not require access to the database.

For pureScale or Database Partitioning Feature (DPF) configurations, the instance owner is automatically granted Cluster Administrator privilege when the cluster domain is created.

Note: In DPF and pureScale environments, the userid of the instance is available on all the hosts.

Special Handling of Cluster Administrator Setup in Mutual Failover (MF) and High Availability Disaster Recovery (HADR)

By default, the instance owner does not have Cluster Administrator privilege, and you need to use root user to run any system and cluster administrative command.

When running in a Mutual Failover (MF) environment, the instance owner is not a good candidate to be granted Cluster Administrator privilege because the instance owner’s home directory is managed by the cluster manager and is only available on one host at a time. For HADR environments, if a different instance name is used for each host, a different user must be configured to be used as Cluster Administrator.

The best practice for configuring a non-root user as Cluster Administrator for MF or HADR environments is to set up a different user using the following procedure:

  1. Create an operating system user on each host in the cluster and add the user to the same primary group as the Db2 instance owner. Ensure that the user’s home directory resides on a filesystem that is not managed by the cluster manager. Additionally, if the SYSADM_GROUP configuration parameter is set to different group than the primary group of the instance owner, then you also need to add the user to the group which is configured as SYSADM_GROUP.

  2. Set up the Db2 environment variables for this user on each host by sourcing the db2profile (Bash or Korn shell) or db2cshrc (C shell) from the local Db2 instance owner’s sqllib directory. It is recommended to source these scripts in the user’s .profile (for Bash or Korn shell) or .bashrc (for Bash shell) or .login (for C shell) so that the Db2 environment variables are automatically set every time the user logs in.

  3. For this user, configure password-less SSH connectivity between all hosts in the cluster. This is required for some administrative commands that require executing a command remotely on another host.
  4. Then as System Administrator (root user on UNIX), run the db2cm –grant -adminUser <userName> command to grant Cluster Administrator privilege to this new user.

Shared file system tasks for db2cm (with the -cfs option)

Anyone with an userid on the system can retrieve information about the current state of the cluster file system using the -list and -verify options. These users can also perform a wide variety of file system operations with the db2cm command options. As long as the userid running the command has read and write ownership of the device being used, that user can create file systems and add disks. Once a file system has been created or mounted, access to that file system is limited to the userid that created it and to the System Administrator. Only those users can remove, delete, or rebalance a file system. These users can also create directories that are accessible to other users, much as with a normal file system.