Almost all of our JESSPOOL Profiles begin with &RACFLNDE.   I want to ensure future profiles in the JESSPOOL class are created with &RACLNDE as well.     So I implemented 2 profiles  C4R.JESSPOOL.ID.** with nothing on the access list.   I implemented C4R.JESSPOOL.ID.&RACLNDE.** with the right groups on the access list.

When I tried to create a new JESSPOOL resource &RACLNDE.AK#TST.** it allowed it to happen which is good.  But when I defined XXXXNODE.AK#TST.** it allowed it to be created too.     I even tried to define C4R.JESSPOOL.%RACLNDE.**  just incase there were issues with the & character.

Is the issue due to &RACLNDE itself or is there an issue with RACFVARS variables?   I know at one time I had issues with &RACLNDE and the Command Verifier /FROM functionality.

Thanks

------------------------------
Linnea Sullivan
------------------------------

Hi Linnea,

I attempted to recreate your scenario on one of my zSecure education systems.
I defined both the Command Verifier profiles C4R.JESSPOOL.ID.** (UACC NONE and no permission to my user ID) and C4R.JESSPOOL.ID.&RACLNDE.** (with my user ID on the ACL with UPDATE access). 
Next, when I tried to define a JESSPOOL profile that was named &RACLNDE.myuserid.**, this define command was unsuccessful. The violation message that I received indicated that my user ID lacked the required UPDATE access to XFACILIT profile C4R.JESSPOOL.ID.**. This seems to indicate that indeed the ampersand in &RACLNDE is not working as you expected. According to me, in this profile Command Verifier treats the &RACLNDE value as a variable instead of as a literal. 
However, when I replaced XFACILIT profile C4R.JESSPOOL.ID.&RACLNDE.** with C4R.JESSPOOL.ID.%RACLNDE.** and then tried to define JESSPOOL profile &RACLNDE.myuserid.** again, this command was successful. And attempting to define a JESSPOOL profile with a different hlq as &RACLNDE failed. If I understand you correctly, this is how you wanted this to work.
I understand that this does not explain why in your system you were authorized to define JESSPOOL profile XXXXNODE.AK#TST.**, but in my opinion, it does illustrate that your scenario can work when you use XFACILIT profile C4R.JESSPOOL.ID.%RACLNDE.**.

I read in your message that you also tried to define XFACILIT profile C4R.JESSPOOL.%RACLNDE.**. I note that this profile lacks the ID qualifier. Is that just a typo or did your forget the ID qualifier in profile C4R.JESSPOOL.ID.%RACLNDE.**?
Hope this helps.



------------------------------
Tom Zeehandelaar
z/OS Security Enablement Specialist - zSecure developer
IBM
Delft
+31643351728
------------------------------

Preventing the XXXXNODE profile should work. Allowing the &RACLNDE via an &RACLNDE policy does not, but using %RACLNDE in the policy should allow/work.

You're not EXEMPT are you?

------------------------------
Guus Bonnes
------------------------------

When you specified a RACFVARS name in the profile key of your XFACILIT C4R.JESSPOOL.ID.&RACLNDE.** policy profile, the values stored as members of the RACFVARS profile were used to build the RACLISTed image of the XFACILT profile (as you would expect).  So in effect you were creating nn profiles (with nn the number of members in &RACLNDE) each protecting a specific node name.  So defining a JESSPOOL profile with one of those node names was allowed.

To learn how RACFVARS names can be used (intentionally) in the profile key of your C.V. policy profiles, read section "RACFVARS profiles" on page 39  (or thereabouts) in the Command Verifier manual.

If you must test that a * or a % is present in the profile you're creating, you should be aware how Command Verifier translates generic characters (and some special characters).  Read section "Generic and special characters in policy profiles" at page 140 (or thereabouts) in the Command Verifier manual

------------------------------
Rob van Hoboken
------------------------------