Top Secret

 View Only
Expand all | Collapse all

dataset masks

  • 1.  dataset masks

    Posted 7 days ago
    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 6 days ago
    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 6 days ago

    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 6 days ago

    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 4 days ago
    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 6 days ago
    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 5 days ago
    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 5 days ago
    Edited by Joe Denison 5 days ago
    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 5 days ago
    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 4 days ago
    (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 4 hours ago
    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 2 hours ago
    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
    ------------------------------