Authorization summary for SETROPTS MLS(FAILURES) and MLS(WARNINGS)

Table 1 shows the required relationship that must exist between the user's security label and the security label of the resource in order for user to gain access to the resource while the SECLABEL class is active and SETROPTS MLS(FAILURES) or MLS(WARNING) is in effect, based on the type of MAC checking and the requested access level.

When SETROPTS MLS is in effect and a user has a security label but the resource does not, the user will fail to gain access to the resource because the authorization checking is done using RACROUTE REQUEST=AUTH. The user will be successful in gaining access when the authorization check is done using RACROUTE REQUEST=FASTAUTH, even when SETROPTS MLS is in effect.

Table 1. Security label authorization checking when SECLABEL class is active and either SETROPTS MLS(FAILURES) or MLS(WARNING) is in effect
Requested access	Normal MAC	Reverse MAC	Equal MAC
Read-only	User dominant	Resource dominant	Equivalent
Read-write	Equivalent	Equivalent	Equivalent
Write-only ¹	Resource dominant ²	Unpredictable ³	Equivalent
Notes®: ¹z/OS does not support write-only requests for data sets or tape volumes. All write-only requests are tested as both read-only and write-only requests. Therefore, the security labels must be equivalent. ² Users cannot write to a resource that has a lower security label than the user's current security label. This inability to writedown is enforced when SETROPTS MLS(FAILURES) is in effect to ensure that a user does not declassify data. ³ The test for write-only is not supported for classes defined with the reverse MAC attribute.