Top Secret

 View Only
Expand all | Collapse all

dataset masks

  • 1.  dataset masks

    Posted Jun 21, 2022 09:44 AM
    searching for broadcom page on TSS dataset masking, specifically use of '*'.

    e.g.  difference between 1) DUMMY    2)  DUMMY.    3)   DUMMY.*    4)   DUMMY.**

    Is there a symbolic for each character?  e.g.   DUMMY.%TEST, DUMMY.%PROD where % can be any 1 position character

    thank you, bobby


  • 2.  RE: dataset masks

    Broadcom Employee
    Posted Jun 22, 2022 07:05 AM
    Bobby,

    1) A permit to "DUMMY" will incorporate any dataset ID prefixed by "DUMMY".

    2) A permit to "DUMMY." imputes the presence of at least two qualifiers
    (i.e., "DUMMY.X", "DUMMY.X.Y", etc.).

    3) Same as (2), previous.

    4) Same as (2), previous.

    A "+" character can be used to replace a single character in the dataset
    mask.

    Please note that "the %" character has a special meaning in a resource ID
    mask (i.e., it is replaced by the current accessor ID), except where "%mn%"
    is coded. In the latter case, the "%mn%" string is replaced by a substring
    of the current accessor ID, beginning at position "m" and extending for "n"
    characters.

    John P. Baker

    --
    This electronic communication and the information and any files transmitted
    with it, or attached to it, are confidential and are intended solely for
    the use of the individual or entity to whom it is addressed and may contain
    information that is confidential, legally privileged, protected by privacy
    laws, or otherwise restricted from disclosure to anyone else. If you are
    not the intended recipient or the person responsible for delivering the
    e-mail to the intended recipient, you are hereby notified that any use,
    copying, distributing, dissemination, forwarding, printing, or copying of
    this e-mail is strictly prohibited. If you received this e-mail in error,
    please return the e-mail to the sender, delete it from your computer, and
    destroy any printed copy of it.




  • 3.  RE: dataset masks

    Posted Jun 22, 2022 07:05 AM

    Bobby,

    Use the + character to mask a single character.   Per your examples, it would be:  DUMMY.+TEST, DUMMY.+PROD 

    The * mask character can represent 0 to 8 characters.  Example:  DUMMY.*PROD

    The % mask character represents the ACID that the auth check is running under. 

    The - mask character accommodates any length of characters (re "floating").  DUMMY.-PROD

    These are described under the "PERMIT Function -- Permit Access to Resources" section of the "Using" section of the CA Top Secret z/OS doc. 



    ------------------------------
    Joe Denison
    joe@tssadmin.com
    CA Top Secret z/OS Productivity Specialist
    Access Solutions, Inc.
    Kansas City, Missouri / USA
    ------------------------------



  • 4.  RE: dataset masks

    Broadcom Employee
    Posted Jun 22, 2022 07:05 AM

    Hi Bobby,

    - The documentation for masking is here:

    https://techdocs.broadcom.com/us/en/ca-mainframe-software/security/ca-top-secret-for-z-os/16-0/administrating/setting-up-resource-definitions-and-ownership/resource-ownership/masking.html#concept.dita_597e3bd3c08d947209955f53328397aac902b396_ACIDSubstitution

    - The differences between 1) DUMMY 2) DUMMY. 3) DUMMY.* 4) DUMMY.** are:
    1) The length of the resource name.
    2) DUMMY includes everything that starts with DUMMY, including DUMMY1, DUMMYXYZ, etc. whereas the other three only include everything that starts with DUMMY. (DUMMY., DUMMY.*, and DUMMY.** include the same datasets.)

    - The '+' masking character represents a single position within a resource name.
    The '%' masking character represents all or part of the signed on ACID.

    Best regards,
    Bob Boerum




  • 5.  RE: dataset masks

    Posted Jun 23, 2022 05:59 PM
    thank you everyone!   as another poster mention difficulty finding info on the internet therefore pleasantly surprised to find one..    regards, bobby


  • 6.  RE: dataset masks

    Posted Jun 22, 2022 07:05 AM
    I always have trouble finding that information in the TSS manuals, but it happens I had to look it up recently for a discussion on the mainframe listserv.  Some of it is in the User Guide starting at p 164.  (I'm using the r15 version, but after that they combined all the manuals into one gigantic PDF.)

    The '+' is a wildcard for a single character.  I may be mistaken, but I believe it cannot substitute for the period in a DSN, unlike the asterisk.

    The percent sign in TSS stands for the current user ACID.

    It says here that the asterisk can substitute for a one- to eight-character index.  THIS IS NOT CORRECT, or rather it's misleading.  Unlike the asterisk in RACF, in TSS it can substitute for ANY ZERO TO EIGHT characters including a period.  This makes it a real problem when trying to mask resource names.  The documentation describes it here and there first in one way and then in the other; if someone has actually tested this and knows that my interpretation is inaccurate, please speak up and say so.

    There is no special meaning for '**' in TSS; it merely means any zero to 16 characters.

    So for your examples:

    DUMMY. matches DUMMY.DATASET.ANYTHING.

    DUMMY matches those; it also matches DUMMYDSN.DATASET.ANYTHING (because no period restricts the meaning).

    DUMMY.* and DUMMY.** match all the same DSNs as the first one does.

    Oh, one thing:  The TSS documentation claims that an asterisk IN THE FIRST POSITION can represent only a single index.  Given the way it's said to behave in the rest of the DSN I would have to test that to be confident of it, but thats what it says.



  • 7.  RE: dataset masks

    Broadcom Employee
    Posted Jun 23, 2022 09:50 AM
    Hi Robert,

    I wanted to make sure a few things were clear in the thread.  The + fixed position masking character does not substitute a period in a DSN as you mentioned.  The other masking characters - and * can substitute a period in a DSN.  The latest section on Masking Characters in the documentation can be found at this URL:

    https://techdocs.broadcom.com/us/en/ca-mainframe-software/security/ca-top-secret-for-z-os/16-0/administrating/setting-up-resource-definitions-and-ownership/resource-ownership/masking.html

    The Concept of DUMMY. matching DUMMY.DATASET.ANYTHING. is not a function of masking, it is a function of generic prefixing.  A generic prefix is defined as a high-order sub-string of the full resource name.  It will allow any resource name that matches the prefix of the rule in Top Secret to be used as the rule to validate access.  The use of generic prefixing is defined in the RDT for the resource class and its functionality can be overridden by enclosing the resource name in single quotes.

    The link to generic prefixing is located here:

    https://techdocs.broadcom.com/us/en/ca-mainframe-software/security/ca-top-secret-for-z-os/16-0/administrating/setting-up-resource-definitions-and-ownership/resource-ownership/generic-prefixing.html

    I would agree that there is no special meaning when a generically prefixed resource name ends with .** It is redundant as the generic prefix would match anything that followed the resource name anyway.  It does have meaning if it was in the middle of a resource name like Dummy.**.ANYTHING.

    I hope this helps.

    Kevin



  • 8.  RE: dataset masks

    Posted Jun 23, 2022 10:35 AM
    Edited by Joe Denison Jun 23, 2022 10:36 AM
    There is one aspect to the use of a trailing mask characters of ** on permissions that is useful and that is to override an existing (same-prefix) permission, and is especially useful for those environments running with AUTH(MERGE) or if a RESCLASS has the MERGE attribute in the RDT.

    For example, consider a case where you have a user who needs READ access to the SYS1.IPLPARM dataset, but one of the user's attached profiles has a permission of DSN(SYS1.IPLPARM) ACC(NONE) (and, it's not feasible to consider removing that profile from the user).  

    If you permit DSN(SYS1.IPLPARM) ACC(READ) to that user ACID (or to any other profile attached to that user), they still cannot read it because the ACC(NONE) will take precedence.  

    However, if you permit DSN(SYS1.IPLPARM**) ACC(READ) to that user, this permission will be considered a better match (i.e., it is the longest), and the user will be provided access designated in this permission.  (EDIT:  originally had a typo in this permission)

    This may be an undocumented or off-label use, but is very useful technique to know, especially when you are in a pinch and in circumstances where time is of the essence to provide the access!

    ------------------------------
    Joe Denison
    joe@tssadmin.com
    CA Top Secret z/OS Productivity Specialist
    Access Solutions, Inc.
    Kansas City, Missouri / USA
    ------------------------------



  • 9.  RE: dataset masks

    Posted Jun 23, 2022 10:40 AM
    A typo in my last post:  the overriding permission should read as:  DSN(SYS1.IPLPARM**) ACC(READ)

    ------------------------------
    Joe Denison
    joe@tssadmin.com
    CA Top Secret z/OS Productivity Specialist
    Access Solutions, Inc.
    Kansas City, Missouri / USA
    ------------------------------



  • 10.  RE: dataset masks

    Posted Jun 23, 2022 03:59 PM
    (I can't believe I'm about to correct Joe Denison!)  One modification, Joe.  It happens my current client uses AUTH(MERGE,ALLOVER), so I've had occasion to look this up:  I believe that MERGE looks at the user ACID first, then all the profiles merged together, then the ALL record.  So in your example below, if you add the permission to any profile the user has, it'll have the effect you described, but if you add it to the user ACID directly it'll work as intended.




  • 11.  RE: dataset masks

    Posted Jun 28, 2022 07:11 AM
    hi joe, for your sample using dataset SYS1.IPLPARM, your saying DSN(SYS1.IPLPARM**)  is better match than DSN(SYS1.IPLPARM) because its "the longest"?      that logic hard to swallow as I see DSN(SYS1.IPLPARM) as an exact match.   

    my other confusion is use of asterick changes if used in the middle versus the end.   if used in middle its 0 to 8 character.   but DUMMY.*.DATA does not cover DUMMY.DATA which i thought was 0 character in the middle?  

    fr RobertBridges:  "DUMMY.* and DUMMY.** match all the same DSNs as the first one does", sounds like asteriCs at end don't make a difference.    DUMMY.* = DUMMY.** is a true statement?    




  • 12.  RE: dataset masks

    Posted Jun 28, 2022 08:47 AM
    Bobby,

    All I can say is that I learned this through experience.  I've seen it in shops, have asked about it and got that explanation, and have played a bit with TSSSIM just to verify that it really works that way. 

    The documentation backs this up by stating that the best fit is the permission with the longest resource name, and apparently trailing mask characters count toward that length.  My theory is that as the algorithm is searching through the permissions, it finds the one for DSN(SYS1.IPLPARM) and makes note that this permission is a match...but as it continues searching, it encounters the DSN(SYS1.IPLPARM**) and also considers this a match ( but is a longer permission, so it is considered the best fit, and therefore becomes the permission that will be used for the decision about access).   One could argue about it being best match (i.e., it's not an EXACT match like the other one without the mask characters), but, the doc clearly states that the permission with the longest resource name is the best fit.  (And it's a handy aspect to know about when you need to use it!)

    Placing a permission with trailing mask characters is mostly something useful in an AUTH(MERGE) environment, where you want to provide (a different level of) access to some users for a dsn/resource, but don't want to remove the profile that has (an undesired level of) access.   You can place the permission with trailing mask characters in the user ACID (or any other profile) and it will be considered a better match/best fit.  Note that you can also place the permission with the trailing mask characters in the same profile as the other permission...but likely there's not a clear use case for that, except maybe for permitting temporary access w/o the need to alter existing permissions (?)

    P.S. Regarding Bob's assertion that a permission to the user ACID overrides the profiles in an AUTH(MERGE,ALLOVER) setting:  I disagree.  The user ACID and all profiles are all merged into a single security record to be searched by the algorithm.  (If I'm wrong, I'll fully admit it ... but I don't think I am here).   Works the same way even in an AUTH(OVERRIDE,ALLOVER) environment for auth checks with a RESCLASS that has the MERGE attribute in the RDT.

    ------------------------------
    Joe Denison
    joe@tssadmin.com
    CA Top Secret z/OS Productivity Specialist
    Access Solutions, Inc.
    Kansas City, Missouri / USA
    ------------------------------



  • 13.  RE: dataset masks

    Posted Jun 28, 2022 05:08 PM
    Right you are, Joe; I just looked it up again.  I should have know better than to contradict The Man :-).


  • 14.  RE: dataset masks

    Posted Jul 12, 2022 04:31 PM
    Hey Joe, great explanation. I've been at this for many years now, and still get tripped up. In fact I'm a bit perplexed by the permit TSS is using in given situation at the moment. 

    Given an acid with these profiles (order as displayed by a TSS LIST)
    PROFILE = JBATCH
    PROFILE = JAAB1

    JBATCH contains a permit for CICS.P++. ACCESS(ALL) ACTION(AUDIT)
    JAAB1 contains a permit for CICS.PAA. ACCESS(ALL)

    As both permits are of the same length, I would have assumed that CICS.PAA. in JAAB1 would be used because it has no masking characters, but a TSSSIM shows CICS.P++. in JBATCH being used to grant access. 

    We are set for AUTH(MERGE,ALLMERGE).

    Anyone able to point out the flaw in my logic? I'm missing something that I should, at my advanced age, know!

    Tom Chicklon


  • 15.  RE: dataset masks

    Posted Jul 12, 2022 05:05 PM
    That occurs because when the permissions are sorted (all together, regardless of profile sequence), the CICS.P++. sorts to the top (of those two permissions).  Since it is encountered first, and the subsequent CICS.PAA. is not considered a more specific match, the 1st one is selected for the match.  Arguably the CICS.PAA. is more specific in regard to the mask characters...but the mask ++ characters aren't considered "less specific" than the AA characters in the other permission. .  Another one of those "that's how it works, you just gotta know it, accept it, and then life will be a lot easier!" things.  :-)

    If there is a need to make the CICS.PAA. permission be considered more specific, you can add one or more trailing * characters so that it is "longer" and it will be selected over the shorter permission.

    ------------------------------
    Joe Denison
    joe@tssadmin.com
    CA Top Secret z/OS Productivity Specialist
    Access Solutions, Inc.
    Kansas City, Missouri / USA
    ------------------------------



  • 16.  RE: dataset masks

    Posted Jul 12, 2022 05:33 PM
    Joe, I suppose another way to get TSS to use the desired permission is to quote the DS name ('CICS.PAA').  But would that work because TSS always prefers quoted DSNs, or merely because the two quotes make the name longer?  I suppose the way to test that is to try two permissions, 'CICS.PAA' and CICS.PAA+++ (the second one being longer) and see which it prefers.


  • 17.  RE: dataset masks

    Posted Jul 13, 2022 05:23 AM
    Edited by Josef Thaler Jul 13, 2022 05:26 AM
    Joe, I like your quote "that's how it works, you just gotta know it, accept it, and then life will be a lot easier!"-things.

    And b
    ased on my observations I'd like to ask back to what you wrote "the permissions are sorted": Isn't it more a merge-sort with the sortkey "resclass+entity", which means that the sequence of permissions having the same sortkey is determined by the sequence of user plus sequence(!) of profiles within this userid (or, the other way round: that the secquence of permissions having the same sortkey is NOT random/occasional). I'm talking about an installation, which has AUTH(MERGE,...) option set.

    This consideration comes into play, when you determine the effective permission, when in the entire "merged" set of permissions within a userid are permissions with the same match (=sortkey). If you rearrange the profiles, this selection can be influenced! 

    a little thing to be added on: 
    What, if you want that both permissions with the same match get effective in due circumstances: E.g.: If you need to audit update access to dataset, but do not need/want to audit read-access to the very same group of datasets: 

    if you admin: 
    TSS PER(MYACID) DSN(CICS.PAA.) ACC(ALL) ACTION(AUDIT)  
    TSS PER(MYACID) DSN(CICS.PAA.) ACC(READ) /* same match! */ 
    and an acid requests READ access, the request gets nevertheless audited because the first permit matches+permits and the second permit has no better match.     

    if you admin:
    TSS PER(MYACID) DSN(CICS.PAA.) ACC(READ) 
    TSS PER(MYACID) DSN(CICS.PAA.) ACC(ALL) ACTION(AUDIT)  /* same match! */ 
    you'll get what you need: Read-access is not audited, accesses beyond READ get audited, because for requests beyond read, the first permit matches, but does not permit. 

    Above two PERMITs could be in different profiles (then sequence of profiles within userid determines the effective permit) or in the same profile (then the sequence of admin-commands determine the effective permit!).

    btw: "TSS LIST(MYACID)" show such permissions in the historical=correct sequence, "TSS LIST(MYACID) ARCHIVE" does NOT! --> again a "that's how it works, you just gotta know it, accept it, and then life will be a lot easier!"-thing! ;-) 

    kind regards,
    Josef 


    Edit: typo reworked....
         

     



       


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



  • 18.  RE: dataset masks

    Posted Jul 13, 2022 11:36 AM
    Hi Josef,

    Keen observations and good explanations!  And, yes of course there's a merge in addition to the sort when the AUTH setting is MERGE.   Also, of course the resclass/resname are the sort key.  Sorry I just assumed that these were a given in the conversation and did not intend to assert otherwise.    :-)

    It's good to know that the permissions across profiles in an AUTH(MERGE) environment remain in the same physical sequence across profiles as they were prior to the sort and are evaluated in that order.   I'm sure TSS does its own sorting/merging, but this concept which maintains the integrity of the original physical input order of duplicate key items is labeled as the EQUALS option in products like DFSORT and SyncSort and is often a default option in effect.

    Your example of placing the ACC(READ) permission prior to the ACC(ALL) ACTION(AUDIT) is a classic ... one of the key fundamental concepts to know as an administrator.   I've run into this before where I needed to include the ACC(READ) permission after the other audited one was already in place, and of course I had to first revoke the ACC(ALL) ACTION(AUDIT) so that when I permitted the READ it would appear first, and then I had to re-permit the ACC(ALL) ACTION(AUDIT) so that it would appear after the non-audited permission.  

    IMO, it is nice that the developers had the insight to sort only on the resname, as this provides some control by the administrator to place the permissions in the desired sequence to be evaluated.  While it's a nuisance to have to revoke/re-permit to insert new permissions above existing (identical resname) ones,  the need isn't frequent in my experience.

    Regarding the TSS LIST with ARCHIVE ... it is interesting to note that the sort of the archived commands includes more than just the resclass/resname ... but also includes keywords on the permission.  If you look closely, you'll see that the keywords seem to be part of the sort key.  And that seems to be the reason that the order is not accurate as compared to a standard TSS LIST.  Restoring the ACID would not rebuild it properly if the commands are run in that order.  It's not clear why the order of the commands in the ARCHIVE output does not otherwise match the order of the standard TSS LIST, but the output order differs in other (benign?) respects as well.

    ------------------------------
    Joe Denison
    joe@tssadmin.com
    CA Top Secret z/OS Productivity Specialist
    Access Solutions, Inc.
    Kansas City, Missouri / USA
    ------------------------------



  • 19.  RE: dataset masks

    Posted Jul 13, 2022 09:29 AM
    Thanks Joe, what you say matches my experience. Certainly not how I would have expected this to work, but appreciate knowing this.

    Our first pass at exploding out permits that start with *. was a bit painful. So removing all of these and adding them back with a trailing * is something I just can't risk.

    The permit that was being remediated was *.P and I mistakenly thought I could add ++. to the end to come up with a standard permit. Looks like we will have to replace these with shorter permits as there are only about 15 of them vs. 8000+ of the CICS.PAA. variety.

    Thanks again!


  • 20.  RE: dataset masks

    Posted Jul 12, 2022 05:18 PM
    When choosing which permission to use, TSS, unlike RACF, doesn't care (as I read the documentation) whether a character is a mask or not.  To a human, CICS.PAA is unquestionably the more specific of the two.  But CICS.P++ is the same length, and that seems to be all that TSS looks for as the starting criterion.

    If you have multiple permissions by the same length, then it looks at other features of the permissions to determine a match.  For instance, if one of them says ACCESS(NONE), that one controls regardless of other matters.  Failing that, it looks at (for example) FACILITY, TIME, TERMINAL and so on.

    I'm not sure what effect ACT(AUDIT) might have on TSS' decision.




  • 21.  RE: dataset masks

    Posted Jun 28, 2022 01:45 PM
    Bobby, it's true that in Joe's example, 'SYS1.IPLPARM' is exactly matched by DSN(SYS1.IPLPARM) and by DSN(SYS1.IPLPARM**).  Joe means than TSS, presented with those two permissions, will choose the latter because it has more characters in it.

    Which is the answer for your question to me, too:  Yes, asterisks at the end of a DSN in a permission don't change anything, in the sense that they match all the same datasets-although, as Joe pointed out, TSS would choose the permission with more characters, given the choice.

    As for your other question, 'DUMMY.DATA' isn't matched by DSN(DUMMY.*.DATA) because if the asterisk represents zero characters it works out to 'DUMMY..DATA', with two periods.  I believe you'll find that 'DUMMY.DATA' would be matched by DSN(DUMMY*DATA), DSN(DUMMY.*DATA) and DSN(DUMMY*.DATA).  If you test it and that doesn't work, I may have to change my mind and say an asterisk represents one to eight characters rather than zero to eight; but I pretty sure I remember the documentation said zero at one point.


  • 22.  RE: dataset masks

    Posted Jun 28, 2022 01:46 PM
    Regarding a DSN(DUMMY.*.DATA) permission:  keep in mind that any non-mask character in the permission *must* be present in the dataset being accessed in order for this permission to match.  So even though the * mask represents 0-8 characters, there would never exist a dataset named DUMMY..DATA (because that's not a valid dataset name).  The coding of both "." characters in the permission is the key reason that DUMMY.DATA would never be matched to this permission ... because that dataset name only has one "." character, and the permission requires two '.' characters to be a match.

    Regarding "DUMMY.* and DUMMY.** match all the same DSNs as the first one does", this is true, both represent generic prefixes, except the one suffixed with ** is longer and would be considered a better match if both permissions were in play.   

    To elaborate: these permissions, independent of one another, provide access to the same scope of datasets, as they are all considered a "generic prefix":

    DSN(DUMMY.)
    DSN(DUMMY.*)
    DSN(DUMMY.**)
    DSN(DUMMY.*****)

    But if more than one of these permissions are in play in the same auth check, the longest one will be considered the best match.



    ------------------------------
    Joe Denison
    joe@tssadmin.com
    CA Top Secret z/OS Productivity Specialist
    Access Solutions, Inc.
    Kansas City, Missouri / USA
    ------------------------------



  • 23.  RE: dataset masks

    Posted Jun 28, 2022 04:20 PM
    hi joe thanks for great techsupport!   believe it or not starting to understand the quirkiness of TSS masking, different from RACF. 

    "longer profile fits best" still digesting that one, my guess is its another option to alter access, create a "longer" to override the "shorter" profile.   so now a user have both which looks confusing.  wouldn't it be better to modify the access level of the "shorter"?           

    my guess for the difference is RACF has a specific class for dataset access including UACC (default/universal access) and ACL (access list).     whereas in TSS, dataset access can be defined in many areas:   profile, userid, ALL, depending on who/what needs it.   there are no dataset "segment".  Direct permit to userid is something we try to avoid.  

    if i lookup a dataset via 3.4, in RACF there is a subcommand i enter left of dataset name which displays the RACF DATASET profile used in securing it.   is there something similar in TSS?      it would be like doing a WHOHAS but in subcommand format.


  • 24.  RE: dataset masks

    Posted Jun 28, 2022 04:55 PM
    In most TSS shops I've worked, they don't use AUTH(MERGE) so each profile is looked at individually; if it provides a match to the resource, TSS doesn't look further.  Then you add profiles using the AFTER or BEFORE parm, which lets you arrange the profiles in a particular order; if one profile allows the user access and another doesn't, you make sure that the one you want comes first in his profile list.  Of course that leads to extra work and you sometimes have to study more to figure out why a user's permissions aren't behaving the way you think they should, but it also gives you more power.

    My current client uses AUTH(MERGE,ALLOVER), which I've never seen before and which sometimes makes it harder to limit access to a particular resource.