IBM Security Z Security

I have several questions on CSDATA reporting.

We are trying to look up the access of 2 dataset profiles and RESOLVING the group access to the User IDs.   We want to include the CSDATA field $FIELD1 from the UserID record.    But for some reason what we are seeing with the look up does not match what is on the user id.  Here is the carla:

 SUP  MSG=(2226,27,28,29,1788,286,293);
 Newlist n=based1 segment=base required allowrestrict,
  ,
  tt="Sensitive Dataset Overview",
  st='Pxx Project' retain
 Select s=base c=dataset,
  profile=('DSN1.NODEA.NODEB.**','DSN2.NODEC.NODED.**')
   sortlist " - complex"(tt,page) complex(tt,page) stamp(tt),
    ,
    searchkey(nd) key(26,wrap)  proftype(1) | warning(1,hb) |,
    erase(1,hb),
    uacc owner acl:$field1,
    acl(sort(ACCESS),universal,resolve) acl:revoke(hb,1) |,
    acl:revoke_inactive(hb,1) acl:name(trunc) acl:dfltgrp(trunc),
    acl:instdata(0,trunc)

How can we lookup the $FIELD1 from the RESOLVED UserID?

Not sure if this was a good decision on our part or not but $FIELD1 is defined to USERIDs and GROUPS, so we have CFIELD for GROUP.CSDATA.$FIELD1 and USER.CSDATA.$FIELD1     Could that cause lookup issues?

Today we use CSDATA heavily on the User ID record, and minimally on Groups, Resources, and Datasets.   But that is going to get larger for Groups, Resources, and Datasets.   So reporting on the CSDATA segments will be very important.    I don't want to bother you guys everytime we have a lookup question.   Is there a sample library, documentation, or other material about using CSDATA segments in reporting.     I had an RFE for reporting on CSDATA that lead to some changes for CSDATA in release 2.5.   But it seems more could be done, I may need to document some scenarios and open up another RFE.

Thanks for your assistance.

 

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

When you use ACL in a SORTLIST or DISPLAY command, make sure you use the same modifiers on all instances of the ACL field.  In your case, you are sorting the main ACL field, but not the base field of the lookups, can you check if the $FIELD1 lookup is based on the default sort order?

The easiest way to overcome this is by adding a line DEFINE $ACL(sort(ACCESS),universal,resolve) as ACL, and using this $ACL field for all instances in your SORTLIST.

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

Thanks, that worked.

Are there any issues of using the same field name on a UserID, Group, and a Resource Profile?

I mentioned we are getting heavier in using CSDATA.    Is there any documentation or sample library of carla that shows examples of using CSDATA?  The ISPF panels don't really offer assistance in situations like this.

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

Original Message:
Sent: Fri June 02, 2023 03:26 AM
From: Rob van Hoboken
Subject: CSDATA Reporting

When you use ACL in a SORTLIST or DISPLAY command, make sure you use the same modifiers on all instances of the ACL field.  In your case, you are sorting the main ACL field, but not the base field of the lookups, can you check if the $FIELD1 lookup is is based on the default sort order?

The easiest way to overcome this is by adding a line DEFINE $ACL(sort(ACCESS),universal,resolve) as ACL, and using this $ACL field for all instances in your SORTLIST.

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

Searching the zSecure 2.5 language reference all I can find is one mention in the section for DEFINE command:

Since release 2.5, the target field can also be a custom field name as defined in the CFIELD class in a RACF database.

The object property lookup works on the currently selected/processing profile, you can use it on any entity type like so:

sortlist profile owner :$field1

ID lookup only works for USER and GROUP references, you used it in your example to find the value of FIELD1 in the corresponding user or group:

sortlist profile acl acl:$field1

You can use the same CFIELD value $FIELD1 on USER and GROUP profiles, zSecure will find the right entity because the name space of these entities do not allow duplicate names.  You can also use the same CFIELD names in other entity types because GENERAL and DATASET only support object property lookups.

I agree, you need a lot of experience with the language and its concepts to interpret the documentation, and even then you (or I) still cannot find an explicit description of the functionality.  Also, language concepts are sometimes just built and never included in samples or panels, when customers ask for the function but exploitation in the panels is too labor-intensive. Sigh.

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

>Not sure if this was a good decision on our part or not but $FIELD1 is defined to USERIDs and GROUPS, so we have CFIELD for GROUP.CSDATA.$FIELD1 and USER.CSDATA.$FIELD1     Could that cause lookup issues?

I think your suspicion is entirely correct. The input parser needs to find what definition to use, so as to get the output width that defines the output layout. So I suspect it just takes the definition it uses from the first one it finds.

------------------------------
Hans Schoone
Chief Architect zSecure
IBM - zSecure architect
Delft
------------------------------

Original Message:
Sent: Thu June 01, 2023 05:12 PM
From: Linnea Sullivan
Subject: CSDATA Reporting

I have several questions on CSDATA reporting.

We are trying to look up the access of 2 dataset profiles and RESOLVING the group access to the User IDs.   We want to include the CSDATA field $FIELD1 from the UserID record.    But for some reason what we are seeing with the look up does not match what is on the user id.  Here is the carla:

 SUP  MSG=(2226,27,28,29,1788,286,293);
 Newlist n=based1 segment=base required allowrestrict,
  ,
  tt="Sensitive Dataset Overview",
  st='Pxx Project' retain
 Select s=base c=dataset,
  profile=('DSN1.NODEA.NODEB.**','DSN2.NODEC.NODED.**')
   sortlist " - complex"(tt,page) complex(tt,page) stamp(tt),
    ,
    searchkey(nd) key(26,wrap)  proftype(1) | warning(1,hb) |,
    erase(1,hb),
    uacc owner acl:$field1,
    acl(sort(ACCESS),universal,resolve) acl:revoke(hb,1) |,
    acl:revoke_inactive(hb,1) acl:name(trunc) acl:dfltgrp(trunc),
    acl:instdata(0,trunc)

How can we lookup the $FIELD1 from the RESOLVED UserID?

Not sure if this was a good decision on our part or not but $FIELD1 is defined to USERIDs and GROUPS, so we have CFIELD for GROUP.CSDATA.$FIELD1 and USER.CSDATA.$FIELD1     Could that cause lookup issues?

Today we use CSDATA heavily on the User ID record, and minimally on Groups, Resources, and Datasets.   But that is going to get larger for Groups, Resources, and Datasets.   So reporting on the CSDATA segments will be very important.    I don't want to bother you guys everytime we have a lookup question.   Is there a sample library, documentation, or other material about using CSDATA segments in reporting.     I had an RFE for reporting on CSDATA that lead to some changes for CSDATA in release 2.5.   But it seems more could be done, I may need to document some scenarios and open up another RFE.

Thanks for your assistance.

 

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