v Anyone with a userid on the system can retrieve information about the current state of the cluster domain using the -list and -verify options. These users can also perform a wide variety of file system operations with the db2cluster command options, but what they can do is constrained by regular file system permissions. 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 DB2 cluster services
administrator, so only those users can remove, delete, or rebalance a file system.
Either the userid that created it, or the DB2 cluster services administrator can create directories that are accessible to other users, much as with a normal file system.
v The DB2 cluster services administrator can perform administrative tasks that affect DB2 cluster services as a whole across all clustered instances on all hosts in the cluster domain. This user can perform change options for the tiebreaker device, using the -set option. As well, the DB2 cluster services administrator can perform maintenance-related tasks, such as putting hosts into maintenance mode, using the -enter option, or committing changes or updates to the shared file system, using the -commit option. This user can also perform advanced maintenance operations on the shared file system cluster, such as creating, deleting, starting, or stopping the domain, and adding or removing hosts;
however, it is strongly recommended that these tasks be performed only under the advisement of DB2 service personnel.
Chapter 2. Roles
Roles simplify the administration and management of privileges by offering an equivalent capability as groups but without the same restrictions.
A role is a database object that groups together one or more privileges and can be assigned to users, groups, PUBLIC, or other roles by using a GRANT statement, or can be assigned to a trusted context by using a CREATE TRUSTED CONTEXT or ALTER TRUSTED CONTEXT statement. A role can be specified for the
SESSION_USER ROLE connection attribute in a workload definition.
Roles provide several advantages that make it easier to manage privileges in a database system:
v Security administrators can control access to their databases in a way that mirrors the structure of their organizations (they can create roles in the database that map directly to the job functions in their organizations).
v Users are granted membership in the roles that reflect their job responsibilities.
As their job responsibilities change, their membership in roles can be easily granted and revoked.
v The assignment of privileges is simplified. Instead of granting the same set of privileges to each individual user in a particular job function, the administrator can grant this set of privileges to a role representing that job function and then grant that role to each user in that job function.
v A role's privileges can be updated and all users who have been granted that role receive the update; the administrator does not need to update the privileges for every user on an individual basis.
v The privileges and authorities granted to roles are always used when you create views, triggers, materialized query tables (MQTs), static SQL and SQL routines, whereas privileges and authorities granted to groups (directly or indirectly) are not used.
This is because the DB2 database system cannot determine when membership in a group changes, as the group is managed by third-party software (for example, the operating system or an LDAP directory). Because roles are managed inside the database, the DB2 database system can determine when authorization changes and act accordingly. Roles granted to groups are not considered, due to the same reason groups are not considered.
v All the roles assigned to a user are enabled when that user establishes a connection, so all privileges and authorities granted to roles are taken into account when a user connects. Roles cannot be explicitly enabled or disabled.
v The security administrator can delegate management of a role to others.
All DB2 privileges and authorities that can be granted within a database can be granted to a role. For example, a role can be granted any of the following authorities and privileges:
v DBADM, SECADM, DATAACCESS, ACCESSCTRL, SQLADM, WLMADM, LOAD, and IMPLICIT_SCHEMA database authorities
v CONNECT, CREATETAB, CREATE_NOT_FENCED, BINDADD,
CREATE_EXTERNAL_ROUTINE, or QUIESCE_CONNECT database authorities v Any database object privilege (including CONTROL)
A user's roles are automatically enabled and considered for authorization when a user connects to a database; you do not need to activate a role by using the SET ROLE statement. For example, when you create a view, a materialized query table (MQT), a trigger, a package, or an SQL routine, the privileges that you gain through roles apply. However, privileges that you gain through roles granted to groups of which you are a member do not apply.
A role does not have an owner. The security administrator can use the WITH ADMIN OPTION clause of the GRANT statement to delegate management of the role to another user, so that the other user can control the role membership.
Restrictions
There are a few restrictions in the use of roles:
v A role cannot own database objects.
v Permissions and roles granted to groups are not considered when you create the following database objects:
– Packages containing static SQL – Views
– Materialized query tables (MQT) – Triggers
– SQL Routines
Only roles granted to the user creating the object or to PUBLIC, directly or indirectly (such as through a role hierarchy), are considered when creating these objects.