Jon, I don't see it as a risk because OPERCMDS access is still required. An OPERCMDS catchall profile of * or ** will protect all commands not otherwise protected and ideally should have few, if any, permissions. OPERCMDS should be locked down without regard to the conduit a user uses to enter commands (e.g., SDSF /, JCL statements, TSO CONSOLE commands). Keep in mind that you can, and should, restrict the use of these various conduits. All MVS.MCSOPER.console-name is doing is controlling what console name they select, and the AUTH setting for that console is superfluous if OPERCMDS is properly protected.
If you want to restrict users to establishing consoles with names that are prefixed with their ID and choose not to implement GLOBAL OPERCMDS MVS.MSCOPER.&RACUID*/READ, you would then need to code a profile for every ID in the OPERCMDS class of MVS.MSCOPER.userid* and permit each user access to their own profile. I think this is burdensome and unnecessary. I think it is of no consequence to let anyone activate a console with a name having their own ID as the prefix. This assumes they are even able to activate a console to begin with, which you can control as discussed above. If a user deviates from using their own ID as the prefix, then perhaps restrict it what they can choose. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.rshconsulting.com -----Original Message----- Date: Wed, 2 Jul 2025 17:28:48 -0500 From: Jon Perryman <[email protected]> Subject: Re: setting up user and operator commands. On Wed, 2 Jul 2025 13:41:54 +0100, Colin Paice <[email protected]> wrote: > COLINX 00000290 CANCEL AAAA > TSU03273 00000090 IEE341I AAAA NOT ACTIVE >There is no * on the front of my console-name An * (asterisk) in the first byte of syslog lines (in this case before console name) should identify a WTOR. Is this referring to something else? >I like your profile MVS.MSCOPER.&RACUID*/READ I haven't used that before >... I'll add it to my list of useful commands. To me, this is a very bad idea. You've opened the first permission in multi-permission system command protection. Maybe there is a typo in a subsequent profile. Maybe insufficient testing. New commands weren't considered in the security design. Is it really so difficult to create a group with read access for something so powerful? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
