Bob makes some very good points here, however a small addition : “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.”
This is true for the action character in question, however be aware that SDSF also has actions like “K” from DA that generate MVS CANCEL commands rather than JES2. Rob Scott Rocket Software From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Robert S. Hansel (RSH) Sent: 08 February 2023 13:00 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RACF - SDSF question EXTERNAL EMAIL 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<http://www.linkedin.com/in/roberthansel> www.rshconsulting.com<http://www.rshconsulting.com> -----Original Message----- Date: Tue, 7 Feb 2023 13:31:41 +0000 From: "Shaffer, Terri" <terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>> 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) terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN ================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
