Last week I discovered that I've been sending our auditors incomplete information since forever. They want to know, for example, who has update access to SYS1.ENDEVOR.PRODSRCE. That should be easy: I run a WHOHAS DATASET(SYS1.ENDEVOR.PRODSRCE), remove all the entries for less-than-ACC(UPD), and then run a REXX Edit macro that expands the listing. (The expansion shows name and last-used date for each ACID, each member of the profiles listed, and everyone who has XA ACID to anything in the list. It runs recursively, so it'll dig deeper if required.) I send them the list, pat myself on the back for being so clever and go back to sleep.
But it turns out that the TSS WHOHAS command doesn't tell me who has DATASET(*****)! Could that be by design? And if it is, is it documented anywhere?
I've now updated my WHOHAS shortcut; when I ask about the DATASET class and not DATASET(*****), it adds DATASET(*****) to the listing. But I have a hard time understanding why it works this way. Maybe there's a fix for this but it isn't applied at either of my clients?
If you issue: TSS WHOOWNS DSN (SYS1.ENDEVOR.PRODSRCE) TSS WHOOWNS DSN(*****) does the same acid own both of these? The WHOHAS command does the equivalent of a WHOOWNS command, and then, for each ownership found, does the equivalent of the original WHOHAS command. When a TSS WHOHAS command is issued, TSS does not search every owned mask, however, if the mask ownership is owned by the same acid as the dataset requested (ie SYS1.ENDEVOR.PRODSRCE), then the masked entry will show up in the output. In other words, if the acid that owned SYS1.ENDEVOR.PRODSRCE also owned *****, then the DSN(*****) permit would show up in the TSS WHOHAS output.
I suspect the acid that owns DSN(SYS1.ENDEVOR.PRODSRCE) is not the same as the acid that owns DSN(*****), in which case this is not an error condition.
I did not see this in the documentation.
If the auditor needs to know every acid that has access to DSN(SYS1.ENDEVOR.PRODSRCE), you will need to find acids that have NODSNCHK, SYS1.ENDEVOR.PRODSRCE permits, and all dataset permits with masking characters that match. Also, if a volume is passed on the dataset call for the SYS1.ENDEVOR.PRODSRCE dataset, you will need to find all acids that have volume access (either to the specific volume or a generic volume permit such as VOLUME(*ALL*(G)) or VOLUME(***) where '***' is a volume prefix for the volume where the dataset resides.) When a dataset is accessed, if a volume is passed on the security call, TSS checks the volume access first and based on the volume access, it allows the access, denies it, or goes to dataset checking. For example, if an acid has UPDATE access to the volume where SYS1.ENDEVOR.PRODSRCE resides and the volume is passed on the security call, the acid can READ or UPDATE SYS1.ENDEVOR.PRODSRCE regardless of what access the acid has to DSN(SYS1.ENDEVOR.PRODSRCE).
If you need assistance with how to find these, please let me know.
Thanks Bob, for these valuable explanations. Just as additional questions: Is NOVOLCHK, PARMLIB(SCHEDxx) PPT ... NOPASS, UID(0) Users, (and more?) relevant to answer the question, who has access to a specific dataset?
NOVOLCHK does not necessarily give access to data sets on the volume. Administrators must enter the NODSNCHK keyword along with NOVOLCHK to allow total access to an entire volume when individual data sets are also being accessed.
In looking at IBM's website, it appears that with DFHSIP coded as an MVS program properties table within the SCHEDxx member of SYS1.PARMLIB with NOPASS coded, NOPASS will bypass authorization checking on data sets accessed by the CICS region. Determining if this is set would have to be done outside of CA Top Secret.
UID(0) would allow access to datasets available through Unix System Services.