Hi Terri, Here are a couple of thoughts to add to what others have mentioned.
Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is superfluous since the resource name never includes the jobname, so you can delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the .** generic suffix applies to zero or more qualifiers, and in this case it is zero qualifiers. The suggestions to lock down MVS cancel job commands won't help in this situation because SDSF is issuing JES2 commands instead of MVS commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked. As was mentioned, to cancel a job typically also requires ALTER access to the JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL profiles to isolate and restrict ALTER access to these jobs. Also consider whether users have been (inadvertently) set up as Destination Operators. If they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing JESSPOOL profile checks. If the CONSOLE class is active, you can permit ID(*) UPDATE access to JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the PERMIT command so that users can only issue JES2 cancel job commands from within SDSF panels. This would prevent them from cancelling jobs outside of SDSF, to include when using the SDSF / command. You would need to remove UACC(UPDATE) or ID(*) UPDATE permission, whichever applies, for the conditional permission to take effect. Operations and Tech Support staff will need 'regular' UPDATE access permission. (CONSOLE is a Default Return Code 8 class, so don't activate it without first creating a ** profile with UACC(READ).) To see exactly what resource names are being checked that are allowing the unwanted job cancellations, issue the SDSF command SET SECTRACE ON, cancel the job, and then issue the SDSF command ULOG. ULOG will show you all the access checks SDSF is making along with the results of each of these checks. SECTRACE is a phenomenal diagnostic tool that we use often. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. *** Celebrating our 30th Anniversary *** 617-969-8211 www.linkedin.com/in/roberthansel www.rshconsulting.com -----Original Message----- Date: Tue, 7 Feb 2023 13:31:41 +0000 From: "Shaffer, Terri" <[email protected]> Subject: RACF - SDSF question Hi, I know there is a RACF group, but hopefully this is simple and I am just missing something I have done 100 times over with no issues. We run our CICS regions as batch jobs, and I just found out a user instead of them issuing a CEMT PERF SHUT command, they are canceling it. Which then causing a 100 vsam messages on startup with all the verifies, and if something goes wrong they call me... So I tried to stop this habit, I know they are putting a C beside the CICS and a $CJ(xxxxx) command So I have 2 rules in RACF under OPERCMDS JES2.CANCEL.BAT.C30TCI* (G) JES2.CANCEL.BAT.** (G) If I restrict the BAT.** then they cant cancel even their own batch jobs, So I always thought more specific is looked at first? One of my previous co-workers implemented SDSF-RACF rules converted from ISFPARMS. Lastly, I understand this doesn’t stop them from canceling any other jobs, but since this is a development shop we allow more access than most. But I don’t want users canceling a CICS or DB2 etc. Any ideas how they are getting the access and not stopped with the more specific rule?? Ms Terri E Shaffer Senior Systems Engineer, z/OS Support: ACIWorldwide – Telecommuter H(412-766-2697) C(412-519-2592) [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
