Hello Terri,
How does your JESJOBS class look like? https://www.ibm.com/docs/en/zos/2.5.0?topic=cujn-controlling-who-can-cancel-jobs-by-job-name -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Shaffer, Terri Sent: Wednesday, April 17, 2024 2:28 PM To: [email protected] Subject: [EXTERNAL] Re: RACF - SDSF question Hi, I would like to resurrect this question again, because my issue is back but not sure if by design or my RACF setup... Because we are a development shop, we allow our developers to start/stop and issue modify commands to shutdown their CICS regions that run as batch Jobs. They are the owners/notify of said regions, However, what I would like to prevent to them Cancelling the regions, due to possible file corruption, etc. They put a C beside a jobname which then issues a $CJ, which then translates into a CANCEL XXXXXXXX,A=xx command. $CJ(5138) CANCEL C30TCIE2,A=0051 IEE301I C30TCIE2 CANCEL COMMAND ACCEPTED $HASP890 JOB(C30TCIE2) 288 $HASP890 JOB(C30TCIE2) STATUS=(EXECUTING/SPS1),CLASS=Y, $HASP890 PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE $HASP890 CANCEL=YES So my question becomes is it even possible to stop this because technically they are the owners? In RACF..... My JESSPOOL class has. *.*.C30TCI*.** (G) My OPERCMDS class has JES2.CANCEL.BAT with them having UPDATE access MVS.CANCEL.JOB.C30TCI* (G) NO access So not sure this is possible or not? Ms Terri E Shaffer Senior Systems Engineer, z/OS Support: ACIWorldwide - Telecommuter H(412-766-2697) C(412-519-2592) [email protected] -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Shaffer, Terri Sent: Wednesday, February 8, 2023 9:09 AM To: [email protected] Subject: Re: RACF - SDSF question EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe. Thank you, with your input and Robs, I now know the order of the checks, which was the piece I didn't fully understand. I have now cleaned up my extra rules and added rules under jesspool and they are now stopped. Rob, thanks for the slides! Ms Terri E Shaffer Senior Systems Engineer, z/OS Support: ACIWorldwide - Telecommuter H(412-766-2697) C(412-519-2592) [email protected] -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Robert S. Hansel (RSH) Sent: Wednesday, February 8, 2023 8:00 AM To: [email protected] Subject: Re: RACF - SDSF question EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe. 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 http://www.linkedin.com/in/roberthansel http://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 ________________________________ [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg ] <http://www.aciworldwide.com/ > This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ________________________________ [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg ] <http://www.aciworldwide.com/ > This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN Unless stated otherwise above: Kyndryl Hungary Korlátolt Felelősségű Társaság / Kyndryl Hungary Llc 8000 Székesfehérvár, Berényi út 72-100. 35. ép Cg.07-09-031714 - registering court: Székesfehérvári Törvényszék Cégbírósága ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
