Resource Classes for JES Security

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.

DATASET

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	NONE Allows no access. READ Allows user to view the datasets list. UPDATE\|CONTROL\|ALTER Allows user to view and delete and create datasets.

JESINPUT

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

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

JESJOBS

JES relation	Entities	ACCESS LEVEL
Controlling the submission and cancellation of jobs by job name.	CANCEL `localnodeid.userid.jobname` (for job cancellation authority) SUBMIT `localnodeid.jobname.userid` (for job submissions) Where `localnodeid` is the name of the enterprise server. These rules are not typically used, but they do provide granularity of control for those environments with special requirements.	NONE Allows no access. READ Allows user to submit jobs UPDATE Equivalent to READ. CONTROL Equivalent to UPDATE. ALTER Allows jobs to be cancelled.

JES relation

Entities

ACCESS LEVEL

Controlling the submission and cancellation of jobs by job name.

CANCEL: localnodeid.userid.jobname (for job cancellation authority)
SUBMIT: localnodeid.jobname.userid (for job submissions)

Where localnodeid is the name of the enterprise server.

These rules are not typically used, but they do provide granularity of control for those environments with special requirements.

NONE: Allows no access.
READ: Allows user to submit jobs
UPDATE: Equivalent to READ.
CONTROL: Equivalent to UPDATE.
ALTER: Allows jobs to be cancelled.

JESSPOOL

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: localnodeid The name of the enterprise server dsnumber The relative dataset number for the job, for exmple, 001 name The dd name. These rules are not typically used, but they do provide granularity of control for those environments with special requirements. Note: In a PAC environment, the enterprise server name must be in parenthesis and prefixed by the PAC name. For example, the following rule trace below specifies EXACLUS as the PAC name and EXACLUS1 is the enterprise server name: EXACLUS1 ESFEM1030I ESM1: MLDAP ESM: SYSAD AUTH request for "EXACLUS(EXACLUS1).SYSAD" in JESSPOOL denied by rule "EXACLUS(EXACLUS1).**"	NONE Allows no access. READ Allows user to view the spool dataset, but not change its attributes. For example, this does not allow the following keywords on the OUTPUT command: NOKEEP, NOHOLD, DELETE, NEWCLASS, and DEST. UPDATE Allows to update a spool dataset. CONTROL Equivalent to UPDATE. ALTER Allows any operand specified on the TSO OUTPUT command, including deleting and printing. Also, when specified for a discrete profile, allows the user to change the profile itself.

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:

localnodeid: The name of the enterprise server
dsnumber: The relative dataset number for the job, for exmple, 001
name: The dd name.

These rules are not typically used, but they do provide granularity of control for those environments with special requirements.

Note: In a PAC environment, the enterprise server name must be in parenthesis and prefixed by the PAC name. For example, the following rule trace below specifies EXACLUS as the PAC name and EXACLUS1 is the enterprise server name:

EXACLUS1 ESFEM1030I ESM1: MLDAP ESM: 
SYSAD AUTH request for "EXACLUS(EXACLUS1).SYSAD" in 
JESSPOOL denied by rule "EXACLUS(EXACLUS1).**"

NONE: Allows no access.
READ: Allows user to view the spool dataset, but not change its attributes. For example, this does not allow the following keywords on the OUTPUT command: NOKEEP, NOHOLD, DELETE, NEWCLASS, and DEST.
UPDATE: Allows to update a spool dataset.
CONTROL: Equivalent to UPDATE.
ALTER: Allows any operand specified on the TSO OUTPUT command, including deleting and printing. Also, when specified for a discrete profile, allows the user to change the profile itself.

PHYSFILE

JES relation	Entities	ACCESS LEVEL
Controls creation of a physical file. See PHYSFILE usage notes section for more information.	Physical files	None, Alter

PROGRAM

JES relation	Entities	ACCESS LEVEL
Controls access to JCL programs. See PROGRAM usage notes section for more information.	Programs	Execute, None

SURROGAT

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

DATASET usage notes

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 EXECUTE 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.

A user that submits jobs must have permission to READ the JCL job file that is being submitted. This is an important security check as it prevents a user from submitting files as JCL jobs when they do not have permission to read those files.

The rule that covers this will also need to cover the reading of a dataset created for the INTRDR submission. It may be that different rules are required as there is a difference between use of the cassub -j command, which will produce a temporary file, and cassub -x, which will pass the whole path and name of the file. The INTRDR cassub command uses the -x option and passes the whole path and name of the dataset.

If the rule that allows the user submitting the job to read the JCL file is based on group membership, the default group of the user submitting the JCL must be one of the groups that allows read access. A user who is a member of one of the groups but does not have a default group set in their security profile must specify the group they are using when they submit the JCL file. That group information cannot be passed through as a property of an INTRDR job generated from the submitted JCL. So the user must specify a default group in their profile which will be used when the check for read permission is made.

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.

PHYSFILE usage notes

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 suggests 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.

Note: The PHYSFILE class is also used by the Remote File Access (RFA) feature. Under RFA, PHYSFILE rules are interpreted differently. Specifically, the default if the class does not exist is to deny access, the "*" and "**" wildcards operate differently, and there are more permission levels available. If you use Remote File Access, see RFA security for more information.

Example

In the following examples 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

PROGRAM usage notes

The PROGRAM security class can be used to limit which user has permissions to run a particular program in a library. The entry takes the format of:

This enables you to grant a user execute access to a program in a particular library but not to a program of the same name in another library.

Program Security Class Example

The symbolic name SYS1.LOADLIB stands for all the utility programs shipped with the product. As such, it is likely that all users should be granted execute permission for programs in that library. In the example below, the PROGRAM class is defined and entries are made to give access to everyone to programs in SYS1.LOADLIB. This entry shows the use of a wildcard to indicate that any program in SYS1.LOADLIB can be used by any user.

The second entry shows a program called CBLMAIN in the library SYS2.LNKLIB. This program can be used by anyone except a user called SAFDSA. If you use the PROGRAM security class, it is more secure to specify each system user and the programs they can access rather than use wildcards to allow all users access to a program or programs in a library.

######################### 
# RACF Class = PROGRAM  # 
#########################
dn:CN=PROGRAM,CN=Enterprise Server Resources,CN=Micro Focus,DC=mftesting,DC=com
changetype: add
objectClass: top
objectClass: container
description: JES Class for controlling access to programs

###########################################
# PROGRAM SYS1.LOADLIB                                            #
# ALLOW ALL USERS ACCESS TO MAIN PROGRAMS  #
###########################################
dn:CN=*.SYS1.LOADLIB,CN=PROGRAM,CN=Enterprise Server Resources,CN=Micro Focus,DC=Program Data,DC=local
changetype: add
objectClass: microfocus-MFDS-Resource
microfocus-MFDS-Resource-Class: PROGRAM
microfocus-MFDS-Resource-ACE: allow:*:execute
microfocus-MFDS-UID: no
description: Allow everyone access to product programs

#########################################
# PROGRAM CBLMAIN.MFI01.MFITEST.LIB2          #
# ALLOW ALL USERS ACCESS TO CBLMAIN             #
#########################################
dn:CN=CBLMAIN.MFI01.MFITEST.LIB2,CN=PROGRAM,CN=Enterprise Server Resources,CN=Micro Focus,DC=Program Data,DC=local
changetype: add
objectClass: microfocus-MFDS-Resource
microfocus-MFDS-Resource-Class: PROGRAM
microfocus-MFDS-Resource-ACE: allow:*:execute
microfocus-MFDS-Resource-ACE: deny:SAFDSA:execute
microfocus-MFDS-UID: no
description: Prevent SAFDSA access to CBLMAIN.MFI01.MFITEST.LIB2 KLIB