IBM Security Z Security

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

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.

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

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

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

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.

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.

Hi Rob,

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

Regards,
Jeroen