IBM Security Z Security

 View Only

 Report SCOPE question in CARLA zSecure

Ivan MANOJLOVIC's profile image
Ivan MANOJLOVIC posted Mon July 07, 2025 06:43 AM

Hello,

When, in zSecure you do a A.2 in front of a userid it's generate a REPORT SCOPE for that user, and you will be able to see every racf ressources that has access to, but if a specific ressource is granted for a user by 2 differents groups, it will only shows one of them. But for a project we need to see all of ressources granted by each groups.

I tried that CARLA :

SUPPRESS REASON=( UACC ID(*) GLOBAL WARNING NOPROF SPECIAL AUDIT,          
GRPAUDIT GRPOPER GRPSPEC OWNER PWDCHANGE SELFCON ALTER-M CKGRACMAP,        
CKGRACDCERT CKGOWNER CREATE)                                               
N REQUIRED N=SCOPE0D       TYPE=REPORT_SCOPE  name=selgroup  outlim=0 
sortlist via                                                              
report scope=useridname                                                       
N REQUIRED N=SCOPE0D       TYPE=REPORT_SCOPE  pl=0 retain                  
select likelist=selgroup                                                  
  sortlist key(nondispl) class,                                            
                     key(both,"Profile name"),                             
  access via                                                               
report scope=selgroup    

but it shows the same results as if I've done a Report Scope directly on the useridname.

Of course I can do manually repeat the report scope line with copying manually all the groups that the user is connected to, but I wish it could be something more user friendly.

Thanks

Jeroen Tiggelman's profile image
Jeroen Tiggelman

Hi Ivan,

The REPORT_SCOPE report type was created to be able to work with the original REPORT SCOPE output in a way that CARLa customizations could be used.
The ACCESS VIA WHEN fields in this report type are not repeated, but supply a particular value that gave the access, much like a resolved or effective ACL.
So I think that the processing you want to do is not possible with this report type.

I think instead you could work with TYPE=RACF and using the SCOPE=id parameter on the NEWLIST statement(s).
See https://www.ibm.com/docs/en/szs/3.1.0?topic=newlist-parameter-descriptions

Regards,
Jeroen

Rob van Hoboken's profile image
Rob van Hoboken IBM Champion

Jeroen is obviously right, report_scope was only built to emulate a report that was constructed 30+ years ago.  Fixing it to show multiple access_via_when paths would break backward compatibility.

Unfortunately, the idea to use NEWLIST TYPE=RACF SCOPE=user_id does not cut muster because this does not provide an effective ACCESS value for user_id and does not have a field VIA at all.  So that's no good.  NEWLIST TYPE=TRUSTED is usually my go-to for listing multiple access paths, but this only shows profiles protecting trusted data sets and resources, so no good.

You can combine the output of several report scopes using mergelist.  This sorts the output but does not resolve different access level that your connect groups may be permitted.

newlist type=report_scope nodup
  sortlist class key access_via_when
mergelist
report scope=user_id
report scope=group_1
report scope=group_2
endmerge

You could use two-pass processing to generate this piece of code:

newlist type=racf dd=ckr2pass nopage name=idsel    
  s class=user s=base key=user_id                   
  sortlist,                                        
  "n type=report_scope nodup",                     
/ "sortlist class key access_via_when",            
/ "mergelist",                                     
/ "report scope=" | key(8)                         
newlist type=racf dd=ckr2pass nopage               
  s likelist=idsel cggrpct>1                       
  sortlist,                                        
"report scope=" | cggrpnm                          
newlist type=racf dd=ckr2pass nopage               
  s likelist=idsel                                 
  sortlist,                                        
"endmerge"                     

Enter this code using menu option CO.C (or CARLA command), or use the C2RC2 proc with inline SYSIN DD.

Jeroen Tiggelman's profile image
Jeroen Tiggelman

Hi Rob,

I don't think REPORT_SCOPE is broken, although it does not provide the information sought after here. I am not sure it is the most likely candidate for an enhancement, since it combines profile and resource level information in a way that is awkward to extend. As for backward compatibility, it would of course be possible to add alternate fields that are not in the backward-compatible layouts.

Perhaps I misinterpreted the request, but pretty much all the REASONs seemed to be excluded. So I thought that this was really about the ID column of an EXPLODEd ACL. You are correct, though, that groups that gave another access level than the effective one would not easily be excluded from a result.

Regards,
Jeroen

Rob van Hoboken's profile image
Rob van Hoboken IBM Champion

I did not intend to mark down REPORT_SCOPE as defective, Jeroen, I should have used extend instead of fix in my opening line:

Fixing Extending it to show multiple access_via_when paths would break backward compatibility.

I dallied with adding a lookup to acl in the sortlist command like so:

newlist type=report_scope 
  sortlist class key access via :acl(explode)
report scope=user_id

which produces useful output but unfortunately the implicit lookup does not recognize defined fields, so adding a subselect needed to answer Ivan's request is of no use:

define type=racf acl(explode) as subselect acl(user=user_id) /* ignored for use in lookup */
newlist type=report_scope 
  sortlist class key access via :acl
report scope=user_id

Jeroen Tiggelman's profile image
Jeroen Tiggelman

Hi Rob,

The DEFINE... SUBSELECT syntax does not have an AS keyword. 
(The parser thinks you have a DEFINE... AS with a field name of SUBSELECT and complains about ACL in a position where only a WHERE clause is allowed.)

You are correct that the DEFINE is ignored in the current GA level.


Early zSecure 3.2 recognizes the DEFINE but does not allow it:
CKR3376 12 Defined variable ACL (type=racf) at CKRCMDV line 3      
           is not boolean/as/true, cannot be used as lookup target 

Regards,
Jeroen

Jeroen Tiggelman's profile image
Jeroen Tiggelman

I didn't mean a lookup to an ACL, though, I was thinking along these lines:

define type=racf acl(explode) subselect acl(user=crmbjti)   
newlist type=racf scope=crmbjti                             
  sortlist class key acl                                  

However, this gives me a lot of profiles where I have access for another reason than a PERMIT (with no indication).
Perhaps it is a usable start for the actual purpose, perhaps not.

Rob van Hoboken's profile image
Rob van Hoboken IBM Champion

Jeroen,

you can add the same SUPPRESS REASON= as Ivan had in the original post to get rid of the "profiles where I have access for another reason than a PERMIT".

However, as I stated before:

Unfortunately, the idea to use NEWLIST TYPE=RACF SCOPE=user_id does not cut muster because this does not provide an effective ACCESS value for user_id and does not have a field VIA at all.

Jeroen Tiggelman's profile image
Jeroen Tiggelman

Hi Rob,

That SUPPRESS reduces the "empty" results, but does not eliminate them.

Regards,
Jeroen