Securing job cancellation in SDSF using ACF2 resource rules

Products

• ACF2
• ACF2 - z/OS
• ACF2 - MISC

Issue/Introduction

When using SDSF to cancel jobs and STCs, ACF2 documentation shows the rule written like this:

$KEY(MVS) TYPE(OPR)
 CANCEL.JOB.- uid(oper) SERVICE(UPDATE) ALLOW
 CANCEL.STC.- uid(oper) SERVICE(UPDATE) ALLOW
 
Actual rule was written like this:

$KEY(JES2) TYPE(OPR)
 CANCEL.JOB.- uid(oper) SERVICE(UPDATE) ALLOW
 CANCEL.STC.- uid(oper) SERVICE(UPDATE) ALLOW
 
But there is still a violation:
 
ACF04056 ACCESS TO RESOURCE JES2.CANCEL.STC TYPE ROPR BY logonid NOT AUTHORIZED

How can cancelling jobs in SDSF be secured using ACF2?

Resolution

When the resource call is made from z/OS, the resource name for JES2 commands is different from MVS commands.  MVS commands are in the format of:
 
MVS.CANCEL.JOB.jobname
MVS.CANCEL.STC.jobname
 
While JES2 commands are in the format of:
 
JES2.CANCEL.JOB
JES2.CANCEL.STC
 
The resource name for the JES2 commands does not have the granularity that MVS commands do which include the jobname or STC name.  ACF2 cannot change this since this is a z/OS call.  JES2 commands will allow the cancellation of all batch jobs and STCs provided the user has the appropriate JESSPOOL access. Granularity support for cancelling jobs and STCs can be provided through JESSPOOL rules. 

Note: Granting JES2 OPERCMD access, but no JESSPOOL access still allows the user to cancel or purge jobs that they own. This is a special administrative consideration in order to prevent having to write rules for users to access their own jobs.  

Additional Information

For more information on securing commands in SDSF, see ACF2 documentation section Using SAF for SDSF External Security