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
>>-GRANT SECURITY LABEL--security-label-name-------------------->
.-,-----------------------------.
V |
>--TO----+-------+--authorization-name-+------------------------>
+-USER--+
+-GROUP-+
'-ROLE--'
.-FOR ALL ACCESS---.
>--+------------------+----------------------------------------><
+-FOR READ ACCESS--+
'-FOR 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