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. :-)
Original Message:
Sent: 08-03-2020 02:03 AM
From: Josef Thaler
Subject: TSS PERMIT dataset name wild-carding behaviour.
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
Original Message:
Sent: 07-29-2020 11:45 AM
From: Chris Williams
Subject: TSS PERMIT dataset name wild-carding behaviour.
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
Original Message:
Sent: 07-29-2020 11:35 AM
From: Josef Thaler
Subject: TSS PERMIT dataset name wild-carding behaviour.
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
Original Message:
Sent: 07-29-2020 11:00 AM
From: Chris Williams
Subject: TSS PERMIT dataset name wild-carding behaviour.
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:
TSS 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
Original Message:
Sent: 07-29-2020 09:02 AM
From: Josef Thaler
Subject: TSS PERMIT dataset name wild-carding behaviour.
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
Original Message:
Sent: 07-29-2020 06:56 AM
From: Chris Williams
Subject: TSS PERMIT dataset name wild-carding behaviour.
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
Original Message:
Sent: 07-29-2020 03:22 AM
From: Josef Thaler
Subject: TSS PERMIT dataset name wild-carding behaviour.
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