Yes, I agree - with my CTLSPEC for ALTUSER (and the right profiles for GroupA) I can operate on GroupA and in that same time with regular Group-Special for GroupB I can also operate on GroupB users with success but I get the message:
Some admins can thinking their commands will be rejected - but no - the RACF group-special commit the change after that message above.
Original Message:
Sent: Thu March 19, 2026 04:13 AM
From: Rob van Hoboken
Subject: Cmd Verifier - =CTLSPEC problem
Hi Sławomir.
Command Verifier's primary purpose was to deny inappropriate commands. The policy profiles would deny a command, even if it was issued by a system special, if a relevant policy profile exists and the user does not have enough access. For example, you can deny some of the system specials from modifying ICSF related profiles, while allowing others full control of them.
Later on, policy functions were added to improve commands, e.g., by adding default values, and temporarily granting a privilege for the command.
So lets look at controlled system special. This allows a command to run with system special, if the parameter in the command match with a policy profile and the user has access. Quoting from the documentation:
Temporary attributes are now applied only for those commands that are allowed, and for which a policy profile exists. So, if somebody wants to change the ADSP attribute and there is no policy profile for setting this attribute, the command is passed to RACF®, which in turn can accept or reject the command. The commands are not run with temporary SPECIAL or temporary AUDITOR because there is no applicable policy profile for the ADSP attribute.
This implies, if there is no policy profile for a parameter in the command, the command is (documented to be) allowed to execute without system special. In your case, it would be allowed to use group special, if there is no policy profile that prevents the command.
Note, if a command is denied the use of temporary system special by an existing policy profile, it won't be allowed to run without the privilege either.
You might want to issue TSO PROFILE WTPMSG to see if a C4R profile denied access to a policy.
------------------------------
Rob van Hoboken
Original Message:
Sent: Tue March 17, 2026 04:04 AM
From: Sławomir Bujniak
Subject: Cmd Verifier - =CTLSPEC problem
Hello
Just a another question - Im connected to (GroupA) and (GroupB with group-Special) having access to C4R.command.=CTLSPEC + accesses for specific C4R profiles for GroupA etc - I will not able to use my group-Special during commands against GroupB objects ?. It says the lack of profiles... Pls just confirm that =CTLSPEC access deprives the group-special benefits for the other groups where the C4R profiles are not defined.
Thank you.
------------------------------
Regards
Sławomir Bujniak
Kyndryl
Original Message:
Sent: Mon August 08, 2022 10:13 AM
From: Rob van Hoboken
Subject: Cmd Verifier - =CTLSPEC problem
Controlled temporary special requires that each parameter specified by the user (that can be protected) is protected by an XFACILIT rule. Check Figure 12 "Policy profiles used to determine whether Controlled Temporary system-level attributes can be assigned" at or around page 52 for the list of resources that must be protected.
The resource you mentioned (C4R.USER.NAME.BGROUP.A11111) suggests that the techuser wanted to change the NAME field of user ID A11111, which is owned by BGROUP. By defining, e.g., C4R.USER.NAME.B*.*, you would allow them to change the name of any user ID owned by a group that starts with a B.
Parameters that are mapped to unprotected resource names are denied for controlled temporary special, unless command verifier has no support for the parameter in the first place.
------------------------------
Rob van Hoboken
------------------------------