Top Secret

 View Only
Expand all | Collapse all

TSS PERMIT dataset name wild-carding behaviour.

  • 1.  TSS PERMIT dataset name wild-carding behaviour.

    Posted Jul 28, 2020 10:48 AM
    Edited by Chris Williams Jul 28, 2020 11:08 AM
    Is there a difference between the following two commands:
    1. TSS PER(CHRISW1) DSNAME(A.B*) ACC(READ)
    2. TSS PER(CHRISW1) DSNAME(A.B) ACC(READ)

    • My understanding is that in (1) above, this would PERMIT access to a data-set with only two qualifiers, the second qualifier starting with 'B' and having zero to seven other characters in that qualifier name.

    • Whereas in (2) above, this would PERMIT access to a data-set with any number of qualifiers, up to a total length of 44 characters.

    It seems to state this in the following CA Broadcom link, under the heading 'Data Set Prefixing', sub-heading 'Variable "*"':
    PERMIT Function-Permit Access to Resources
    Broadcom remove preview
    PERMIT Function-Permit Access to Resources
    View this on Broadcom >

    ...yet after testing this, both commands seem to PERMIT access to a data-set with any number of qualifiers, up to a total length of 44 characters.

    Does anyone have any thoughts on why is this please?
    I would've expected each command to behave according to the web reference, as is my understanding above?

    ------------------------------
    Senior Software Support Consultant
    RSM Partners Limited
    ------------------------------


  • 2.  RE: TSS PERMIT dataset name wild-carding behaviour.

    Posted Jul 29, 2020 03:22 AM
    Edited by Josef Thaler Jul 29, 2020 05:20 AM
    ​Hello Chris,

    ... just from the top of my head:

    - I believe resclass DATASET is/defaults to ATTR(GENERIC). This is a separate attribute from MASK/NOMASK. From that perspective, the DSNAMEs in your permits are equivalent. (could not yet find this in the docs)
    - You could try to specify the dataset-pattern in apostrophes ->  TSS PER(CHRISW1) DSNAME('A.B*') ACC(READ)  -> this could result in the expected effect,
    - I consider it as essential, that the behaviour of the product absolutely corresponds to the web reference. Any errors, inaccuracies and incompletnesses should be reworked.  

    Kind regards,
    Josef      

    Hello Chris,

    ... just from the top of my head:

    - I believe resclass DATASET is/defaults to ATTR(GENERIC). This is a separate attribute from MASK/NOMASK. From that perspective, the DSNAMEs in your permits are equivalent. (I could not yet find this in the docs)
    - You could try to specify the dataset-pattern in quotation marks -> TSS PER(CHRISW1) DSNAME('A.B*') ACC(READ) -> this could result in the expected effect, find "quotation marks" at DSNAME Resource class 
    - I consider it as essential, that the behaviour of the product absolutely corresponds to the web reference and vice versa. Any errors, inaccuracies and incompletnesses should be reworked.

    Kind regards,
    Josef



  • 3.  RE: TSS PERMIT dataset name wild-carding behaviour.

    Posted Jul 29, 2020 06:57 AM

    Hi Josef,


    Thank you for your reply, I very much appreciated it, thank you.

    I think you're right about the RESCLASS DATASET defaulting to ATTR(GENERIC), and absolutely this is a separate attribute from MASK/NOMASK. So I agree with you, this makes the DSNAME Resources in my PERMITs equivalent, and this wasn't what I was trying to achieve unfortunately. The only place I found anything of relevance in the CA web documentation on 'DSNAMES' was at the following link:
    https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/security/ca-top-secret-for-z-os/16-0/using/issuing-commands-to-communicate-administrative-requirements/resources/dsname-resource-class-secure-data-sets.html
    ...but this offers only a very basic description of the 'DSNAME Resource Class' without going into any detail about attributes that may affect it.

    You suggested specifying the DSNAME in apostrophes, a very good suggestion I might add:
    TSS PER(CHRISW1) DSNAME('A.B*') ACC(READ)
    ...unfortunately I've already tried this and the result is the same, it PERMITs access to a data-set with any number of qualifiers, up to a total length of 44 characters, not the result I was hoping for or wanting.

    I agree with you, I too consider it essential that the behaviour of the product should absolutely correspond to the web reference. It's just unfortunate that in this respect the CA web reference seems lacking?!

    Before my testing, I'd searched the CA web references and found the following on the PERMIT Function:
    https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/security/ca-top-secret-for-z-os/16-0/using/issuing-commands-to-communicate-administrative-requirements/command-functions/permit-function-permit-access-to-resources.html
    ...and under the heading 'Data Set Prefixing', sub-heading 'Variable "*"', it seemed to suggest my expected understanding (see original message) would be the result, albeit the CA web reference describes a scenario with the asterisk "*" either embedded or at the front of a data-set name qualifier and not the end of a data-set name qualifier! Interestingly enough, the IBM web documentation on RACF behaviour:

    https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha400/ich2a40030.htm

    …describes the result exactly as I would expect regards generic data set profile names, providing you have Enhanced Generic Naming (EGN) active, see 'Table 1'.

    The TSS behaviour, I'm seeing, may be the result of how the Resource has been set up in the RDT, so I searched on this in the CA web documentation and found:

    https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/security/ca-top-secret-for-z-os/16-0/using/maintaining-special-security-records/maintain-the-rdt-record.html

    https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/security/ca-top-secret-for-z-os/16-0/using/maintaining-special-security-records/maintain-the-rdt-record/change-values-in-the-rdt.html

    https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/security/ca-top-secret-for-z-os/16-0/using/maintaining-special-security-records/maintain-the-rdt-record/define-a-resource-to-the-rdt.html

    …but nothing in these references suggested what the outcome would be with:

    TSS PER(CHRISW1) DSNAME(A.B*) ACC(READ)

    Finally, when I listed my RDT definition for Datasets, using the 'TSS LIST(RDT)' command:

    =================================================================

    RESOURCE CLASS = DATASET                                                  

     RESOURCE CODE = X'0C4'                                                   

         ATTRIBUTE = MASKABLE,MAXOWN(26),MAXPERMIT(044),ACCESS,LIB,PRIVPGM    

            ACCESS = NONE(0000),FETCH(8000),UPDATE(6000),READ(4000),WRITE(2000)

            ACCESS = CREATE(1000),SCRATCH(0800),CONTROL(0400),INQUIRE(0080)   

            ACCESS = SET(0040),ALL(FFFF)                                      

            DEFACC = READ                                                     

    =================================================================

    ….this, again, didn't offer any further help as to why my two original PERMITS:

    TSS PER(CHRISW1) DSNAME(A.B*) ACC(READ)

    TSS PER(CHRISW1) DSNAME(A.B) ACC(READ)

    …both allowed a PERMIT accessing a data-set with any number of qualifiers, up to a total length of 44 characters. Unfortunately, the CA web documentation on the 'TSS LIST(RDT)' command:

    https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/security/ca-top-secret-for-z-os/16-0/using/maintaining-special-security-records/maintain-the-rdt-record/list-the-entire-rdt-record.html

    …is very brief, and doesn't 'expand on' or gives any 'links to' any of the displayed parameters.

     

    In conclusion, the PERMIT in CA's TSS product:

    TSS PER(CHRISW1) DSNAME(A.B*) ACC(READ)

    …seems to behave in an unexpected way, whereas the same PERMIT in IBM's RACF product:

    PERMIT 'A.B*' GENERIC CLASS(DATASET) ID(CHRISW1) ACCESS(READ)

    …behaves as expected, access to a data-set with only two qualifiers, the second qualifier starting with 'B' and having zero to seven other characters in that qualifier name.

     

    With all that said, if any one else can offer an explanation, or shed any light on, why my two PERMITS:

    TSS PER(CHRISW1) DSNAME(A.B*) ACC(READ)

    TSS PER(CHRISW1) DSNAME(A.B) ACC(READ)

    …behave the same in CA's TSS product, I'd be really grateful? 😊

    I look forward to any replies.

     

    Kind regards
    Chris Williams



    ------------------------------
    Senior Software Support Consultant
    RSM Partners Limited
    ------------------------------



  • 4.  RE: TSS PERMIT dataset name wild-carding behaviour.

    Posted Jul 29, 2020 09:03 AM
    Hi Chris,

    my too quick remembrance, that we have had in the past some DSNAME-permissions with dataset name between quotation marks AND masking character is unfortunately not correct for today: I just tested it: Here a command like TSS PER(CHRISW1) DSNAME('A.B*') ACC(READ) gets rejected with message TSS0214E. Sorry about the potential confusion raised by my previous post! 

    But what works: A command like TSS PER(CHRISW1) DSNAME('A.B') ACC(READ) only permits a dataset A.B and not A.B.C. But that does not yet address your intention :-( ... 

    Kind regards, 
    Josef


    ------------------------------
    Josef
    ------------------------------



  • 5.  RE: TSS PERMIT dataset name wild-carding behaviour.

    Posted Jul 29, 2020 11:00 AM
    Hi Josef,


    You caused no confusion in your previous post, quite the contrary, you confirmed I hadn't missed the bleeding obvious. I am very grateful to you, especially as you replied so quickly and you're the only person to reply so far. :-)

    Also, you're latest post confirms and supports the behaviour I'm seeing as well. You're right, what does work, DSNAME('A.B'), isn't what I'm actually trying to achieve in this instance, unfortunately.

    I wonder if any one else, in this community, has experienced two PERMITs:
    T
    SS PER(CHRISW1) DSNAME(A.B*) ACC(READ)
    TSS PER(CHRISW1) DSNAME(A.B) ACC(READ)
    ...giving the same result, i.e. permitting access to a data-set with any number of qualifiers, up to a total length of 44 characters? If they have, how did they get around this problem? If this does turn out to be a 'bug', is it 'known' and is there a fix for it I wonder?

    I look forward to any further replies on this please. :-)


    Kind regards
    Chris Williams






    ------------------------------
    Senior Software Support Consultant
    RSM Partners Limited
    ------------------------------



  • 6.  RE: TSS PERMIT dataset name wild-carding behaviour.

    Posted Jul 29, 2020 11:35 AM
    Chris,

    What you are experiencing is the norm for generic resource class IDs, where the resource class ID specified in the permit is treated as a resource ID prefix.

    If your requirement is to be able to issue RACF-style permits, then you must change resource class ID "DATASET" to "NONGENERIC".

    Please note that for this resource class ID, this is NOT a minor task, and is certainly NOT for the faint of heart.

    ------------------------------
    John P. Baker
    ------------------------------



  • 7.  RE: TSS PERMIT dataset name wild-carding behaviour.

    Posted Jul 29, 2020 11:43 AM
    Hi John,


    Thank you for this, really very much appreciated.

    I'll test this out and see if it achieves what I'm trying to do. :-)


    Kind regard
    Chris Williams.

    ------------------------------
    Senior Software Support Consultant
    RSM Partners Limited
    ------------------------------



  • 8.  RE: TSS PERMIT dataset name wild-carding behaviour.

    Posted Jul 29, 2020 11:51 AM
    Chris,

    Get assistance from Broadcom before making any attempt to make this change.

    This change is very complex and you can get into a lot of trouble very easily.

    ------------------------------
    John P. Baker
    ------------------------------



  • 9.  RE: TSS PERMIT dataset name wild-carding behaviour.

    Posted Jul 29, 2020 11:56 AM
    Duly noted John, much appreciated for the 'heads-up' and kind words of warning.  :-)


    Kind regards
    Chris


    ------------------------------
    Senior Software Support Consultant
    RSM Partners Limited
    ------------------------------



  • 10.  RE: TSS PERMIT dataset name wild-carding behaviour.

    Posted Jul 29, 2020 11:36 AM
    Hi Chris,
    just another quick approach ...
    What about
    TSS PER(CHRISW1) DSNAME(A.B*) ACC(READ) plus
    TSS PER(CHRISW1) DSNAME(A.B*.) ACC(NONE)
    or 
    TSS PER(CHRISW1) DSNAME(A.B*) ACC(READ) plus
    TSS PER(CHRISW1) DSNAME(A.B++++++++.) ACC(NONE)
    [I did NOT test these or other variations] 

    In general I prefer not to have ACC(NONE)-permissions, but perhaps here it could simplify the admin.

    In my understanding the different permissions
    TSS PER(CHRISW1) DSNAME(A.B*) ACC(READ)
    TSS PER(CHRISW1) DSNAME(A.B) ACC(READ)
    are effectively equivalent, assuming that ATTR(GENERIC) is in effect for resclass DATASET. (I guess, you might not want to replace the RDT entry with ATTR(NOTGENERIC) ;-) ) A trailing asteriks (*) could be seen as redundant for such resource-classes. I see the same behaviour not as a bug. (but of course I'm teachable about special circumstances ...)   


    Kind regards and stay safe,
    Josef

    ------------------------------
    Josef
    ------------------------------



  • 11.  RE: TSS PERMIT dataset name wild-carding behaviour.

    Posted Jul 29, 2020 11:45 AM
    Hi Josef,


    Thank you for this, again, really very much appreciated all of your great suggestions. :-)

    I'll test this out, along with John's kind suggestion above, and see if it achieves what I'm trying to do. :-)

    When done, I'll post what worked for me...it may help some other poor unfortunate soul that finds themselves in the same predicament as me! :-)


    Kind regard
    Chris Williams.

    ------------------------------
    Senior Software Support Consultant
    RSM Partners Limited
    ------------------------------



  • 12.  RE: TSS PERMIT dataset name wild-carding behaviour.

    Posted Aug 03, 2020 02:04 AM
    Hi Chris,

    I also understand and underline John's advice to be careful and get assist, as a change in RDT-DATASET ATTR(NOTGENERIC) would affect every dataset-permission not only the permissions in your specific example.

    Let me bring in a different approach: What about, if you rename all the datasets, which permissions you need to be restricted (and for which GENERIC undercuts your intention) to a different name -> ALTER 'A.B*' NEWNAME('A.C*'). Then you can admin the permissions in a granular way.

    Of course this would also need the application to be changed and is an adaption of your dataset naming standards. Just to think about it ...

    Kind regards,
    Josef  


    ------------------------------
    Josef
    ------------------------------



  • 13.  RE: TSS PERMIT dataset name wild-carding behaviour.

    Posted Aug 04, 2020 04:35 AM
    Hi Josef,


    That's a great new approach, I'll test it and see if that satisfies my customer's needs.

    Thank you again, really appreciate all  your fantastic help and advice. :-)


    Kind regards
    Chris Williams

    ------------------------------
    Senior Software Support Consultant
    RSM Partners Limited
    ------------------------------