GRANT (security label) statement

This form of the GRANT statement grants a label-based access control (LBAC) security label to a user, group, or role for read access, write access, or for both read and write access.

Invocation

This statement can be embedded in an application program or issued through the use of dynamic SQL statements. It is an executable statement that can be dynamically prepared only if DYNAMICRULES run behavior is in effect for the package (SQLSTATE 42509).

Authorization

The privileges held by the authorization ID of the statement must include SECADM authority.

Syntax

Read syntax diagramSkip visual syntax diagramGRANT SECURITY LABELsecurity-label-name TO ,USERGROUPROLEauthorization-name FOR ALL ACCESSFOR READ ACCESSFOR WRITE ACCESS

Description

SECURITY LABEL security-label-name
Grants the security label security-label-name. The name must be qualified with a security policy (SQLSTATE 42704) and must identify a security label that exists at the current server (SQLSTATE 42704).
TO
Specifies to whom the specified security label is granted.
USER
Specifies that the authorization-name identifies a user.
GROUP
Specifies that the authorization-name identifies a group name.
ROLE
Specifies that the authorization-name identifies a role name. The role name must exist at the current server (SQLSTATE 42704).
authorization-name,...
Lists the authorization IDs of one or more users, groups, or roles.
FOR ALL ACCESS
Indicates that the security label is to be granted for both read access and write access.
FOR READ ACCESS
Indicates that the security label is to be granted for read access only.
FOR WRITE ACCESS
Indicates that the security label is to be granted for write access only.

Rules

  • For each authorization-name specified, if neither USER, GROUP, nor ROLE is specified, then:
    • If the security plug-in in effect for the instance cannot determine the status of the authorization-name, an error is returned (SQLSTATE 56092).
    • If the authorization-name is defined as ROLE in the database, and as either GROUP or USER according to the security plug-in in effect, an error is returned (SQLSTATE 56092).
    • If the authorization-name is defined according to the security plug-in in effect as both USER and GROUP, an error is returned (SQLSTATE 56092).
    • If the authorization-name is defined according to the security plug-in in effect as USER only, or if it is undefined, USER is assumed.
    • If the authorization-name is defined according to the security plug-in in effect as GROUP only, GROUP is assumed.
    • If the authorization-name is defined in the database as ROLE only, ROLE is assumed.
  • For any given security policy, an authorization-name can be granted at most one security label from that policy for read access and one for write access. If the grantee already holds a security label for the type of access (read or write) indicated and that is part of the security policy that qualifies security-label-name, an error is returned (SQLSTATE 428GR).
  • If the security policy is not defined to consider access through groups or roles, any security label granted to a group or role is ignored when access is attempted.
  • If an authorization-name holds different security labels for read access and write access, the security labels must meet the following criteria (SQLSTATE 428GQ):
    • If any component in the security labels is of type ARRAY then the value for that component must be the same in both security labels.
    • If any component in the security labels is of type SET then every element in the value for that component in the write security label must also be part of the value for that component in the read security label.
    • If any component in the security labels is of type TREE then every element in the value for that component in the write security label must be the same as or a descendent of one of the elements in the value for that same component in the read security label.

Notes

  • By default when a security policy is created, only security labels granted to an individual user are considered. To have groups or roles considered for the security policy, you must issue the ALTER SECURITY POLICY statement and specify USE GROUP AUTHORIZATION or USE ROLE AUTHORIZATION as applicable.

Example

The following statement grants two security labels to user GUYLAINE. The security label EMPLOYEESECLABELREAD is granted for read access and the security label EMPLOYEESECLABELWRITE is granted for write access. Both security labels are part of the security policy DATA_ACCESS. 
   GRANT SECURITY LABEL DATA_ACCESS.EMPLOYEESECLABELREAD
     TO USER GUYLAINE FOR READ ACCESS

   GRANT SECURITY LABEL DATA_ACCESS.EMPLOYEESECLABELWRITE
     TO USER GUYLAINE FOR WRITE ACCESS
The same user is now granted the security label BEGINNER for both read and write access. This does not cause an error, because BEGINNER is part of the security policy CLASSPOLICY, and the security labels already held are part of the security policy DATA_ACCESS. 
   GRANT SECURITY LABEL CLASSPOLICY.BEGINNER
     TO USER GUYLAINE FOR ALL ACCESS