Access Specifications

The list of users to whom the security label is granted can optionally be followed by keywords that specify the type of access to data that the security policy of the label protects

FOR WRITE ACCESS
These keywords restrict the label to the write access rules of IDSLBACRULES, namely IDLSBACWRITEARRAY, IDLSBACWRITESET, and IDLSBACWRITETREE. These rules affect INSERT, DELETE, and UPDATE operations on protected data.
FOR READ ACCESS
These keywords restrict the label to the read access rules of IDSLBACRULES, namely IDLSBACWREADARRAY, IDLSBACREADSET, and IDLSBACREADTREE. These rules affect SELECT, DELETE, and UPDATE operations on protected data.
FOR ALL ACCESS
These keywords apply the label to all of the read and write access rules that are listed above. If the GRANT SECURITY LABEL statement includes no FOR ... ACCESS specification, this option takes effect as the default.

For more information about these IDSLBACRULES rules for label-based read and write access, see Rules Associated with a Security Policy. For information about exemptions to these rules that can be granted for a specific security policy, see Rules on Which Exemptions Are Granted.

If a user is granted a different security label for read access than for write access, then the values given for the security label components must follow these rules:

For security label components of type ARRAY, the value must be the same in both security labels.
For security label components of type SET, the values given in the security label used for WRITE access must be a subset of the values given in the security label used for READ access. If all of the values are the same, this is interpreted as being a subset, and is allowed.
For security label components of type TREE, every element in the tree component of the security label for write access must be either an element or a descendent of an element in the tree component of the security label for read access.

In summary, when DBSECADM attempts to grant a security label for read access to a user who already holds a security label for write access, or vice versa, the read label cannot be more restrictive than the write label. Otherwise, the GRANT SECURITY LABEL statement fails with an error.

A user can be granted no more than two labels for the same security policy. If two labels are granted for the same policy, one label must be for read access and the other for write access. If DBSECADM attempts to grant a security label for read access to a user who already holds a security label for read access that is based on the same security policy, the GRANT SECURITY LABEL statement fails with an error. A similar failure result if both labels are for write access and are on the same security policy.

In both of these cases, the first security label must be revoked explicitly by the REVOKE SECURITY LABEL statement before a second label can be granted for the same access mode and the same security policy. The only exception to this rule is if both labels specify the same values for component elements, because in this case both security labels are functionally identical, and no error is issued.