Valid on z/OS, z/VSE, and z/VM.
Use the PERMIT command function to authorize ACIDs full or restricted access to resource they do not own.
Use the PERMIT command function to control:
Resource ownership means that the user, profile, or control ACID has an access level of ALL. It may not be desirable to grant unlimited access to individual users or profiles, CA Top Secret administrators should assign resource ownership to department or division ACIDs using the ADDTO command function.
Administrators must have the appropriate resource(XAUTH) authority, via the TSS ADMIN command function, to PERMIT access to owned resources within their administrative scope. Note that RESOURCE(XAUTH) allows administrators to PERMIT access to all owned resources within their administrative scope. Administrators must also have explicit authority to use each access level keyword.
Given the proper administrative authority, an CA Top Secret administrator may allow any ACID to access a resource, even if the ACID is outside of the administrator's scope. The resource, however, must be within the administrator's scope of authority.
All resources defined to the RDT can also be used with the PERMIT/REVOKE command function.
A resource must be owned before access can be permitted.
Resources may not be permitted to group, zone, department, or division ACIDs.
This command function has the following format:
TSS PERMIT(acid) keyword(p‑fix)
ACCESS(level)
keyword(oper)
Specifies the ACID of user or job for whom access is being permitted.
Specifies the keyword for type of resource to which access is being permitted. For example DSNAME and VOLUME
Specifies the prefix or resource name. A specific level of ACCESS to the resource, if applicable; if no entry is made, CA Top Secret usually assigns a default access level based on the resource type. For example, the default for data set is READ.
Specifies the manner in which a resource can be used once accessed. For example NONE, READ, and WRITE.
Additional access keywords and their associated options. For example: DAYS(WEEKENDS), LIBRARY(SYS2.TESTLIB), and ACTION(FAIL)
CA Top Secret allows the use of prefixing and masking for resource identification. Therefore, an administrator can enter multiple permissions to the same resource for the same user. A REVOKE command can remove a single or multiple permissions. CA Top Secret uses a security validation algorithm to determine whether a resource access request should be granted or denied. For information on this algorithm, see the User Guide.
This command function uses the keywords:
No duplicate permissions are stored in the CA Top Secret Security File. If a permission is issued to a user or profile that exactly matches an existing permission, CA Top Secret will issue PERMIT FUNCTION SUCCESSFUL. No error messages are issued since the administrator requested that the permit be stored with the user or profile, and CA Top Secret verified that this request was accomplished.
The matching criteria require that all fields coded on the new permit exactly match the existing permission. If the new permit or existing permission has extra parameters, this would not constitute a match and the new permit would be stored on the Security File.
CA Top Secret searches a user's entire Security Record before making an access determination. This determination, in part, is based on the permission that contains a resource name or prefix that is the “best match” for the resource name or prefix being requested. This best match is based on the length of the prefix. If USER01 requests access to data set 'AB.CD' and CA Top Secret encounters the following entries during its security validation search:
TSS PERMIT(USER01) DSNAME(AB.C)
ACCESS(UPDATE)
TSS PERMIT(USER01) DSNAME(AB)
Then CA Top Secret will grant access to the PERMIT containing AB.C since this data set prefix is the best match for the requested 'AB.CD'.
If CA Top Secret encounters two matching PERMITs with equal prefix lengths while searching a Security Record, the access determination is based on the following process:
You can issue a specific REVOKE to remove one permission by listing the user/profiles XAUTH data, and then issuing the REVOKE exactly as it appears in the listing. For example, the output of the following TSS LIST command would enable the authorization following it to be revoked:
XA DATASET = SYS1.PROCLIB ACCESS = READ PRIVPGM = IEBCOPY
TSS REVOKE(user) DSNAME(SYS1.PROCLIB)
ACCESS(READ)
PRIVPGM(IEBCOPY)
Even if there were other permissions with different access levels or other criteria, only this permission would be revoked.
Everything that can be coded on a PERMIT can be coded on a REVOKE with the exception of the FOR parameter. In this situation, the FOR parameter will list as the UNTIL parameter. Therefore, only the UNTIL parameter should be used with the TSS REVOKE command function.
If you code the REVOKE with only the resource and no other parameters, then all matches of the resource are revoked.
Example: revoke permission
This example revokes all permissions that match it.
TSS REVOKE(user) DSNAME(SYS1.PROCLIB)
The RDT attribute, NONGENERIC, causes a general resource to be treated as a fully qualified name rather than as a generic prefix.
Note: The GENERIC/NONGENERIC attribute affects security resource checks, it has no effect on CICS Bypass List processing.
The NONGENERIC attribute can support both long and short resource classes. This attribute does not, however, support the resources that support masking characters.
For example, an administrator can permit a user to resource OTRAN(PSRV), which would allow access to PSRV as well as PSRVTEST or any other OTRAN whose first four characters match the prefix, PSRV. If the NONGENERIC attribute is activated, a permit to OTRAN(PSRV), however, only allows the user to execute transaction PSRV and not PSRVTEST. In order for the user to be allowed to issue either transaction, the permit must be done to OTRAN(PSRV(G)).
To alter a particular general resource class to conform to the non‑generic attribute, enter:
TSS REPLACE(RDT) RESCLASS(OTRAN)
ATTR(NONGENERIC)
The OTRAN keyword is the resource class to be altered.
To remove the NONGENERIC attribute, enter:
TSS REPLACE(RDT) RESCLASS(OTRAN)
ATTR(GENERIC)
When changing the resource class from GENERIC to NONGENERIC, or from NONGENERIC to GENERIC, the security validation behavior for all existing definitions is preserved. However, resources will list differently and administrative commands which follow will have a different effect.
For example, if an attribute of a resource class is changed from GENERIC to NONGENERIC, any resource permitted prior to the change displays a (G) to indicate the cross‑authorization remains GENERIC.
Also, attempts to revoke such a permit may fail, with either TSS0384E: “RESOURCE NOT FOUND IN SECURITY RECORD”, (if the (G) is not included on the REVOKE statement), or TSS0244E: “INVALID SUBFIELD LENGTH FOR KEYWORD ‑ keyword” (if the (G) is included).
In this case, the attribute of the resource class should be temporarily changed back from NONGENERIC to GENERIC (when no other administration is taking place). The REVOKE (without the (G)) should then succeed, and the resource attribute may again be changed to NONGENERIC.
The NONGENERIC attribute applies to the following resources by default:
Resource masking allows administrators to group resources with similar characteristics. Special characters are specified to represent variations between resource names. Prefixing allows administrators to group similar resources defined by CA Top Secret simultaneously.
Note: Resource classes may also be administered to support masking characters by manipulating the RDT MASK/NOMASK attribute.
An administrator can PERMIT access to all owned resources within a NOMASK resource class by using the special resource name:
*ALL*
For resource classes with the MASK attribute, a similar PERMIT can be managed with the resource name:
*****
Adding this resource is a formality and has no effect on resources not already protected. Its main importance is with PERMIT because it allows the administrator to allow access to all owned resources of a RESCLASS. This is a different concept than applying the DEFPROT attribute to a resource class. When DEFPROT is applied, all resources are implicitly protected without the necessity of formal ownership; in order to grant access under DEFPROT, the administrator must still own and permit the resources (which may include *ALL*).
Prefixing allows the CA Top Secret administrator to group a set of similar data sets together, and define them by a 2 to 26 character prefix. For example, all data sets used by the Publications Department could be prefixed by TECHPUBS. Then, the administrator could PERMIT a user to access any data set prefixed by TECHPUBS.
TSS PERMIT(USER01) DSNAME(TECHPUBS.)
This eliminates the need to permit access to 'TECHPUBS.PROD.SCEDS' and 'TECHPUBS.GRAPHICS.SCEDS'.
A prefix may span several data sets name index levels. For example, DSNAME(TECHPUBS.PR).
Resource masking is another method of reducing the number of resource definitions required to implement widespread protection. Masking allows administrators to group resources with similar characteristics, and use special characters to represent variations between resource names.
The character "‑" represents a variable number of characters. The following table provides an example of floating:
|
Entry: |
Matches: |
But Not: |
|
ACCT‑VEND
|
ACCTPAY.VENDOR |
ACC.VEND |
|
ACCTVEND |
AP.ACC.VEND |
In this case, the entry indicates that a matching prefix must begin with the characters ACCT, followed by a variable number of characters represented by a “‑”, and must end with the characters VEND.
The prefix ACC.VEND does not begin with ACCT and therefore does not match the entry.
Floating characters can cross node (also called qualifier or index) boundaries. Floating characters cannot be used with other mask types.
The asterisk “*” can be used to represent zero to eight characters. The following table details variable usage:
|
Entry: |
Matches: |
But Not: |
|
ACCT*M.DATA |
ACCTPAYM.DATA |
ACCTPAYD.DATA |
|
*LAB |
LAB |
NEW.JERSEY.LAB |
|
*RAT |
TESTRAT.LAB |
TRAP.ALL.RATS |
In the first entry, the asterisk is used to represent zero to eight characters between ACCT and M; thus the entry matches ACCT.PAYM but not ACCTPAYD. In the second entry, *LAB does not match NEW.JERSEY.LAB since NEW.JERSEY is more than eight characters long. Multiple asterisks can be listed in series to equal up to 44 characters; therefore, **LAB would match NEW.JERSEY.LAB.
The characters “.*.” or “*.” appearing at the beginning of the data set name are used to represent a one to eight character index. The following table details index usage:
|
Entry: |
Matches: |
But Not: |
|
*.BALL |
BASKET.BALL |
BALL.GAME |
|
CICS.*.*.F |
CICS.RUM.TSS.FIL |
CICS.FEATURES |
The index mask is an extension of the variable mask that allows the CA Top Secret administrator to specify where index levels must appear in a data set name. The first entry specifies that .BALL must be prefixed by one to eight characters; therefore, the data set BALL.GAME does not match this definition. The second entry specifies that two indexes must appear between CICS. and .F. CICS.FEATURES contains no indexes between CICS. and .F and therefore does not match the mask.
The character “+” is used to represent any single character within a data set name. The following table includes examples of the fixed position "+" usage:
|
Entry: |
Matches: |
But Not: |
|
A123+.TSO |
A1234.TSO |
A123.TSO |
|
ACC+VEND |
ACCTVEND |
AP.ACC.VEND |
The character “%” represents the ACID of the user specified in the TSS command.
If TSS PERMIT(USER52) DSNAME(%.MAIL) ACCESS(ALL), then USER52 will have full access to the data set named USER52.MAIL.
This capability can be used to permit all TSO users full access to data sets prefixed by their ACID.
The MSCA must own the "%." character. Only the MSCA can own a special character.
TSS ADDTO(MSCA acid) DSNAME(%.)
An CA Top Secret Administrator may now PERMIT all TSO users to have all access to any data set prefixed by an ACID.
TSS PERMIT(ALL) DSNAME(%.)
FACILITY(TSO)
ACCESS(ALL)
CA Top Secret recognizes a special technique to specify a portion of the userid used as a mask. The special technique uses the % character in conjunction with values identifying the start and length of the userid being entered.
Example: using the %
This example permits TUSER01 access to data set USER01:
TSS PERMIT(TUSER01) DSNAME(%26%)
All masking characters, except the floating mask, may be combined. The following table provides an example of how you can and cannot combine masks:
|
Entry: |
Matches: |
But Not: |
|
MAR++.*.SUM |
MAR86.A.SUM |
MARCH.SUM |
An example of an illegal combination is:
CSSY.*‑83 BOTL‑WORK+++.COMP
Floating characters “‑” may not be combined with other masking characters.
Prefixing allows the CA Top Secret administrator to group a set of similar minidisks together, and define them by one generic prefix. For example, all of user MAINT's 19x minidisks (like 0190, 019D, 019E) could be grouped together using a generic prefix.
Masking (or “patterning”) is another method of reducing the number of definitions required to implement widespread minidisk protection. Masking allows administrators to group minidisks with similar characteristics, and use special characters to represent variations between minidisks.
The asterisk (*) can be used to represent zero to eight characters. The following table provides an example of asterisk usage:
|
Entry: |
Matches: |
But Not: |
|
PAY*.019
|
PAYUSER1.0191 |
PAYDEPT.0391 |
|
PAY.0191 |
PRODUCTS.0191 |
|
|
PAY03.0192 |
PAY.0091 |
In the first entry, the asterisk is used to represent any 0 to 8 characters between PAY and (.); thus the entry matches PAYUSER1.0191 but not PAYDEPT.0391. The characters (.019) are a simple prefix; the first three characters of the device address or device number must match them exactly.
The character “+” is used to represent any single character within a minidisk name. The following table provides an example of fixed position "+" usage:
|
Entry: |
Matches: |
But Not: |
|
PAY+++.0191 |
PAYROL.0191 |
PAYDEPT.0191 |
The character “%” represents the ACID of the user requesting access.
If TSS PERMIT(USER01) VMMDISK(%019), then USER01 will have full access to minidisks USER01.0191, USER01.019E, and so on.
This capability can be used to permit all VM ACIDs access to minidisks prefixed by their own ACID.
The MSCA must own the "%." character. Note that only the MSCA can own this special character.
TSS ADDTO(MSCA acid) VMMDISK(%.)
An CA Top Secret administrator may now PERMIT all VM users to have ALL access to any minidisk prefixed by their ACID.
TSS PERMIT(ALL) VMMDISK(%.)
FACILITY(VM)
ACCESS(ALL)
Mask characters may be combined with the exception of a dash (‑). The following table provides an example of combinations
|
Entry: |
Matches: |
But Not: |
|
SUP*1.+91 |
SUPMAH1.191 |
SUPMAH.191 |
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|