The table below defines the name of each default resource class used in Enterprise Server for JES security, its meaning, the type of resource entities it contains, and the minimum permission that a user requires on the entities.
| JES relation | Entities | ACCESS LEVEL |
|---|---|---|
| Controls use of a dataset; it verifies that a user has access to a dataset. | Files | None, Read, Update, Alter |
| Access to the list of datasets in ESMAC
See the DATASET usage notes section below. |
nodename.userid |
|
| JES relation | Entities | ACCESS LEVEL |
|---|---|---|
| Conditional access support for commands or jobs entered into the system through a JES input device. | INTRDR = Jobs submitted via Internal Reader as a result of executing JCL.
STCINRDR=Jobs submitted via Internal Reader as a result of the execution of a CICS or IMS transaction. TSUINRDR = Jobs submitted via the ESMAC JES "Control" page and/or the cassub command line interface. |
None, Read |
| JES relation | Entities | ACCESS LEVEL |
|---|---|---|
| Controlling the submission and cancellation of jobs by job name. |
These rules are not typically used, but they do provide granularity of control for those environments with special requirements. |
|
| JES relation | Entities | ACCESS LEVEL |
|---|---|---|
| Controlling access to job datasets on the JES spool (Joblog, SYSOUT and Messages. |
localnodeid.userid.jobname.jobid.dsnumber.name
where
These rules are not typically used, but they do provide granularity of control for those environments with special requirements. |
|
| JES relation | Entities | ACCESS LEVEL |
|---|---|---|
| Controls creation of a physical file.
See the PHYSFILE usage notes section below. |
Physical files | None, Alter |
| JES relation | Entities | ACCESS LEVEL |
|---|---|---|
| JES Class for controlling access to job submission by surrogates. If UserA wants to submit a job to run as UserB then he must have "Read" access to the SURROGAT class for entity UserB.SUBMIT |
execution-userid
.SUBMIT
For example, if USERA is USERB's surrogate, Enterprise Server will check that USERA has read access for the entity, USERB.SUBMIT in the SURROGAT class. |
None, Read |
Access rights to files within the dataset are enforced if you have a mainframe dialect Compiler directive set. To ensure that security is also applied if you are not using a mainframe dialect, set the FCDCAT and ASSIGN"EXTERNAL" compiler directives, then ensure files are not assigned dynamically or statically in a SELECT statement.
When security is enabled, and a JCL job is submitted that uses a PROC or INCLUDE file that is part of a cataloged Partitioned Dataset (PO), READ access for the dataset is checked. If the user does not have permission to read the dataset, an error is reported.
When security is enabled, and a JCL job is submitted that includes either JOBLIB or STEPLIB entries, the system checks that the user has READ access to each of the Partition Datasets (PO). If the user does not have the required access, the job abends with a COND CODE of S913.
To view the catalog, it is necessary for the logged-on user to have access to the DATASET resource. You can achieve this with a nodename.userid resource format entry, for example MSSDEMO.MyJESusr.
An example LDIF definition for DATASET can be found in the es_default_ldap.ldf file, which is available from the bin directory of your product installation directory.
The PHYSFILE security class controls creation of physical files, including spool files. It is checked when a file is created or renamed. It is not required that the PHYSFILE class is implemented, and if the PHYSFILE class does not exist, access is permitted. Note that in this case, an access check is still made (and if the Security Auditing feature is enabled, an access-denied audit record will be generated, unless the allow unknown resources option is enabled in the security configuration), but the JES engine treats a security result of "denied because resource class undefined" as an "allow" result.
Micro Focus strongly recommends implementing PHYSFILE rules to restrict where datasets may be created, so that datasets are only created in locations that are within the system working set. This will prevent users from specifying an inappropriate location.
Relationship with DATASET
The DATASET class is used to verify that a user can access a dataset in a given way - read, write, create or delete a dataset - and is checked each time the dataset is accessed. The PHYSFILE class is only checked at dataset creation, and is used to verify that the user can create a dataset in that location.
Relationship with JESSPOOL
Spool files are also datasets, and the PHYSFILE check will be made when these are created to verify that the user who is running the JCL job can create the spool files in the given location. The JESSPOOL security class is used to verify that a user can access the spool files that have been created by a job.
The user id used to submit and run the job must have authority to create the job log files. These are spool files that will be created in the spool files location, and so a PHYSFILE rule to allow access to this location would be required.
Below is an example LDIF definition for PHYSFILE.
Micro Focus would suggest allowing all users access to defined areas, and restrict certain areas to certain users. Allocation override rules can be used in combination with PHYSFILE settings to mandate where datasets are created, based on catalog properties, and who has permission to create them.
In the examples below, it is assumed that all datasets are to be created in an area on disk called C:\WORKAREA. The definition of rules that allows access to specific areas implicitly denies access to areas not covered by the rules.
######################### # RACF Class = PHYSFILE # ######################### dn:CN=PHYSFILE, CN=PHYSFILE,CN=Enterprise Server Resources,CN=Micro Focus,CN=Program Data,DC=local changetype: add objectClass: top objectClass: container description: JES Class for controlling access to physical files ################################### # ALLOW ALL USERS PERMISSION TO # # CREATE FILES IN THE DATA AREA # ################################### dn:CN=C\3A\\WORKAREA\\DATA\\**,CN=PHYSFILE,CN=Enterprise Server Resources,CN=Micro Focus,CN=Program Data,DC=local changetype: add objectClass: microfocus-MFDS-Resource microfocus-MFDS-Resource-Class: PHYSFILE microfocus-MFDS-Resource-ACE: allow:*:alter microfocus-MFDS-UID: no description: Allow everyone permission to create a physical file in the DATA area ################################### # IF SPOOL FILES ARE HELD IN A # # DIFFERENT LOCATION ALLOW ALL # # USERS PERMISSION TO CREATE # # FILES IN THE SPOOL AREA # ################################### dn:CN=C\3A\\WORKAREA\\SPOOL\\**,CN=PHYSFILE,CN=Enterprise Server Resources,CN=Micro Focus,CN=Program Data,DC=local changetype: add objectClass: microfocus-MFDS-Resource microfocus-MFDS-Resource-Class: PHYSFILE microfocus-MFDS-Resource-ACE: allow:*:alter microfocus-MFDS-UID: no description: Allow everyone permission to create job logs and spool fiels in the SPOOL area #################################### # LIMIT ACCESS TO THE MFI01 FOLDER # # TO AUTOUSER # #################################### dn:CN=C\3A\\WORKAREA\\MFI01\\**,CN=PHYSFILE,CN=Enterprise Server Resources,CN=Micro Focus,CN=Program Data,DC=local changetype: add objectClass: microfocus-MFDS-Resource microfocus-MFDS-Resource-Class: PHYSFILE microfocus-MFDS-Resource-ACE: allow:AUTOUSER:alter microfocus-MFDS-UID: no description: Allow AUTOUSER permission to create datasets in the MFI01 folder ##################################### # PHYSICAL FILES IN XYZ FOLDER # # THIS SHOWS RESTRICTING USE OF A # # FOLDER AND SUB-FOLDERS TO A GROUP # ##################################### dn:CN=D\3A\\WORKAREA\\XYZ\\**,CN=PHYSFILE,CN=Enterprise Server Resources,CN=Micro Focus,CN=Program Data,DC=local changetype: add objectClass: microfocus-MFDS-Resource microfocus-MFDS-Resource-Class:PHYSFILE microfocus-MFDS-Resource-ACE: allow:ALLUSER group:alter microfocus-MFDS-UID: mfuid