Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
On Sat, 20 Jun 2020 18:09:35 -0500, Walt Farrell wrote: > >Time Of Check To Time Of Use. As you're making the check, a security >administrator might be changing the rules. Your program might end up getting a >false positive or false negative. >... >It is much simpler, and safer, and in general more robust, to simply issue the >OPEN in the proper program environment and let the system say Yes or No. > As strongly as I agree with that, a programmer might have a sincere wish to avoid the side effects of a prior operation. Suppose a job successfully allocates GDG(+1) then access to another data set fails. The job does nothing useful but the generation is incremented. That programmer wishes, ideally, that the initiator could verify access permissions for all resources mentioned in JCL in the same atomic operation in which it obtains ENQs. But it's not realistic to wish for Logical Unit of Work encapsulation of batch jobs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
On Sat, 13 Jun 2020 23:32:02 -0400, Bob Bridges wrote: >Gil, you mustn't think I plan to make it a habit but I think I'm going to >disagree with you on every point, here: > >o Well, maybe not on the first one: What's "TOCTTOU"? Time Of Check To Time Of Use. As you're making the check, a security administrator might be changing the rules. Your program might end up getting a false positive or false negative. > >o Access rules are indeed complicated to simulate. But why simulate them? >Just > ask RACROUTE and get an answer. Mind you a) I'm a security geek, so maybe > the > rules seem less complicated to me. And b) I've never used RACROUTE directly; > as a security geek I talk to RACF/ACF2/TSS through their TSO-level commands, > so maybe RACROUTE is more difficult. The rules for properly issuing RACROUTE REQUEST=AUTH are what is complicated. Ignoring resources other than MVS data sets, you need to process differently for non-VSAM vs VSAM. For either, you need to first check whether the data set is indicated as possibly having a discrete profile. For non-VSAM, that means reading the DSCB from the VTOC. For VSAM, it means reading the (if I remember correctly) Sphere record from the proper catalog (which you also have to figure out) to determine the cluster name. Then you need to read the RACF indicator from the catalog entry for the cluster name (not the component name you may be opening). Then, for VSAM, you need to specify the cluster name (not the component name that may appear in the JCL). Failure to do any of those properly will give you a potentially wrong answer, or an answer that is right in many cases but wrong in edge cases. Then, there is the difficulty that if your program is not the one that will actually do the OPEN, you may simply get the wrong answer because RACF allows access rules like "user X can use data set Y but only when running program Z". If you are not part of program Z, the answer you get from the RACROUTE will differ from the answer that Z would get if it actually performed the OPEN. So, you might get the wrong answer, and again it might be a false positive or a false negative. Also, if your program is not running authorized, or (more precisely) does not actually require authorization, there are ways a clever user can bypass the check you're doing if your program is running in an environment they can control, such as TSO or batch or a UNIX shell. There are additional considerations if you are asking about the authority of a user other than the one you're running under. It is much simpler, and safer, and in general more robust, to simply issue the OPEN in the proper program environment and let the system say Yes or No. -- Walt (former member of the RACF Design/Development team) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
OPEN was also notorious for giving a return code in R15 rather than an ABEND, leading to program checks in low storage when the program did a GET or PUT without checking whether the DCB was in fact open. SDome programmers can't even spell DCBOFLGS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Sunday, June 14, 2020 5:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET On Sun, 14 Jun 2020 15:51:25 -0400, Bob Bridges wrote: > >B5> Ok, so things change; I still don't see why that means one shouldn't ask. >How is partial information (that is, it'll work under most circumstances but >not under all) worse than no information at all? One can't be sure that the >logic will continue to work at some hypothetical point in the future, when the >system has changed in some way - if that were a bar to asking the question, >how would we ever write ~any~ program? > This works well if the query supports a ternary response: o Allow o Prohibit o Didn't understand (possibly syntax error) The third case might impel a redesign. What does LISTDSD reply for a syntax error, possibly a zFS path? >G4> A security jock should treat an access query with a negative reply as a >violation as serious as attempting the access and failing. > >B5> "As serious"? So you think attempting the access and failing is a serious >violation (at least to some extent)? Yet you're advocating that he do just >that. > The question was posed those years ago by a programmer afflicted with a stodgy security jock who investigated and possibly wrote up any prohibited access attempt. The questioner was seeking a process to avoid such interactions. >G2> Better just to try the access and report any failure. > >B5> Having said all of the above, I'm now reconsidering, not for security >reasons but operational. One of the main reasons I approve of people being >allowed to ask the do-I-have-access question ahead of time is to allow >controled exit from a program if the answer is negative, rather than the >program bombing. But then, you can exit in a controled manner if you try and >fail, too; you just trap the result, or check the RC, and decide then whether >to continue. In that sense there's no real advantage to asking ahead of time. > >In fact from a coding point of view it's probably simpler just to try it and >trap the result, because if you ask the question, then attempt the access, >then trap the result anyway (just in case your question wasn't answered >correctly, for any reason), your program has to do more. > In my view, OPEN was notorious for ABENDing rather than setting status in R15. I suppose that was to protect the programmer from ignoring R15. But I'd expect a programmer who did so simply to get the ABEND on the first I/O operation. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
Doesn't IBM itself do such checks in order to determine which path to take in some routines? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Monday, June 15, 2020 8:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET A security jock should treat an access query with a negative reply as a violation as serious as attempting the access and failing. All should agree. That's one of the reason that customers can request logging of such requests. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
Hi Folks, Just wanted to say that I've posted David Spiegel's Assembler program and REXX to File 836 on the Updates page, as 3 members: RACROUTE (assembler program), RACRAUTH (rexx), and RACROUT$ (assembly JCL). I would recommend renaming the RACRAUTH rexx to something like DSAUTH, but for the purpose of posting on that file, I had to keep the member names related to each other. I also changed the load module name to RACROUT, so as not to confuse with the macro. Examples: From userid USER42: dsauth 'USER43.ISPF.ISPPROF' REASON CODE IN DECIMAL IS 0 00 THE USER HAS NO ACCESS. 04 THE USER HAS READ AUTHORITY. 08 THE USER HAS UPDATE AUTHORITY. 12 THE USER HAS CONTROL AUTHORITY. 16 THE USER HAS ALTER AUTHORITY The UACC of profile USER43.* is NONE. Another example: dsauth sys1.linklib REASON CODE IN DECIMAL IS 16 00 THE USER HAS NO ACCESS. 04 THE USER HAS READ AUTHORITY. 08 THE USER HAS UPDATE AUTHORITY. 12 THE USER HAS CONTROL AUTHORITY. 16 THE USER HAS ALTER AUTHORITY This userid has ALTER access to SYS1.LINKLIB. I don't know if that's safe, but that's the fact, and it's nice to know it. In any case, you get the idea. All the best of everything to all of you. Stay safe. Sincerely, Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
A security jock should treat an access query with a negative reply as a violation as serious as attempting the access and failing. All should agree. That's one of the reason that customers can request logging of such requests. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
On 14 Jun 2020 14:55:45 -0700, in bit.listserv.ibm-main (Message-ID:<0385558663798702.wa.paulgboulderaim@listserv.ua.edu>) 000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote: G4> A security jock should treat an access query with a negative reply as a violation as serious as attempting the access and failing. B5> "As serious"? So you think attempting the access and failing is a serious violation (at least to some extent)? Yet you're advocating that he do just that. The question was posed those years ago by a programmer afflicted with a stodgy security jock who investigated and possibly wrote up any prohibited access attempt. The questioner was seeking a process to avoid such interactions. I know of a case where someone used repeated LISTDSDs to find a non-catalogued APF library that wasn't properly secured. (Despite the long time passed, I won't identify a company or an individual.) So, even though it wasn't many LISTDSD commands showing no access, it proved a way in for someone who shouldn't have had it. A series of security failures against APF libraries would at least have showed the problem up, though maybe not in realtime. I believe that LISTDSD can now be secured. CBT file 106 already requires APF authorization. But I now realize that David Spiegel's program opens up the same potential that unprotected LISTDSD does. If it hadn't been for this conversation, I probably wouldn't have recognized it as a possible problem. So, since I'm a "professional paranoid", I now wonder about the OP's requirement (doubly so, since he isn't even a member of the Listserv). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
On Sun, 14 Jun 2020 15:51:25 -0400, Bob Bridges wrote: > >B5> Ok, so things change; I still don't see why that means one shouldn't ask. >How is partial information (that is, it'll work under most circumstances but >not under all) worse than no information at all? One can't be sure that the >logic will continue to work at some hypothetical point in the future, when the >system has changed in some way - if that were a bar to asking the question, >how would we ever write ~any~ program? > This works well if the query supports a ternary response: o Allow o Prohibit o Didn't understand (possibly syntax error) The third case might impel a redesign. What does LISTDSD reply for a syntax error, possibly a zFS path? >G4> A security jock should treat an access query with a negative reply as a >violation as serious as attempting the access and failing. > >B5> "As serious"? So you think attempting the access and failing is a serious >violation (at least to some extent)? Yet you're advocating that he do just >that. > The question was posed those years ago by a programmer afflicted with a stodgy security jock who investigated and possibly wrote up any prohibited access attempt. The questioner was seeking a process to avoid such interactions. >G2> Better just to try the access and report any failure. > >B5> Having said all of the above, I'm now reconsidering, not for security >reasons but operational. One of the main reasons I approve of people being >allowed to ask the do-I-have-access question ahead of time is to allow >controled exit from a program if the answer is negative, rather than the >program bombing. But then, you can exit in a controled manner if you try and >fail, too; you just trap the result, or check the RC, and decide then whether >to continue. In that sense there's no real advantage to asking ahead of time. > >In fact from a coding point of view it's probably simpler just to try it and >trap the result, because if you ask the question, then attempt the access, >then trap the result anyway (just in case your question wasn't answered >correctly, for any reason), your program has to do more. > In my view, OPEN was notorious for ABENDing rather than setting status in R15. I suppose that was to protect the programmer from ignoring R15. But I'd expect a programmer who did so simply to get the ABEND on the first I/O operation. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
Further comments below. -Original Message- From: Bob Bridges [mailto:robhbrid...@gmail.com] Sent: Saturday, June 13, 2020 23:32 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, June 13, 2020 22:09 G2> Don't. The rules are subject to change. B3> Of course the rules are subject to change. I can't see that that makes any difference - makes it any less handy to know what the rules are. If he takes your advice (just try the access and report the failure), the rule may ~still~ change; so what? G4> I'm thinking not of merely rule changes, but major structural changes. Do David's suggested Assembler and Rexx programs, LISTDSD, and CBT file 106 work alike for Classic data sets and for //SYSUT1 DD PATH=...? Did they work immediately when OMVS was introduced? (I've read that one of the ISV security products rapidly accommodated OMVS paths, but with the restriction that pathnames were limited to 44 characters(?!) and treated as case-insensitive.) B5> Ok, so things change; I still don't see why that means one shouldn't ask. How is partial information (that is, it'll work under most circumstances but not under all) worse than no information at all? One can't be sure that the logic will continue to work at some hypothetical point in the future, when the system has changed in some way - if that were a bar to asking the question, how would we ever write ~any~ program? G2> There's a TOCTTOU hazard. B5> Same objection here. You ask the question, and there's a slight chance the answer happens to change in the next half-second. So how are you worse off than if you hadn't asked in the first place? G2> You may need elevated privilege even to perform the check. B3> I've never had occasion to try in it TSS or ACF2 - being a security jock, I always ~have~ the elevated privileges, so I'm generally unaware of how they behave for hoi polloi - but I know that it's possible even for regular folks to use the RACF commands to determine whether they have read access to a dataset. I don't know about update. G4> A security jock should treat an access query with a negative reply as a violation as serious as attempting the access and failing. B5> "As serious"? So you think attempting the access and failing is a serious violation (at least to some extent)? Yet you're advocating that he do just that. G4> In particular, a programmer scanning the catalog and querying access to every data set should be deemed a (fe)malefactor. There might be reason to protect querying access more strictly than actually attempting the access. B5> It's true that a malefactor might (probably would) use exactly that method to find datasets he could read. It doesn't follow that asking the question is always or even usually malefaction. I'm remembering a virus-hunting program we used some years ago at one of my employers. The idea was to take a segment of some firewall logs and look for probable malware behavior. One IP address hitting another IP address tens of thousands of times was nothing to worry about. Hundreds of addresses hitting one, the same. But one IP address hitting hundreds of IP addresses, each one at a time - that's the behavior of a virus trying to spread itself. This is exactly the sort of thing you're talking about, asking the access question about hundreds of datasets. So it's an interesting point: You might monitor the use of the LISTDSD command, and if you find a user executing it hundreds of times, each for a different dataset, your antennae should start quivering. But I don't see that as a reason to keep everyone from asking at all. --- G2> Better just to try the access and report any failure. B5> Having said all of the above, I'm now reconsidering, not for security reasons but operational. One of the main reasons I approve of people being allowed to ask the do-I-have-access question ahead of time is to allow controled exit from a program if the answer is negative, rather than the program bombing. But then, you can exit in a controled manner if you try and fail, too; you just trap the result, or check the RC, and decide then whether to continue. In that sense there's no real advantage to asking ahead of time. In fact from a coding point of view it's probably simpler just to try it and trap the result, because if you ask the question, then attempt the access, then trap the result anyway (just in case your question wasn't answered correctly, for any reason), your program has to do more. And from the system's point of view, it's less of a drain to attempt it and fail (and catch the error) than it is to ask the question, then attempt the access - because the second way RACF has to answer the question twice. And if one program does that, the extra drain won't be measureable - but if they all do it, the burden on RACF may double. So although I don't see a
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
On Sat, 13 Jun 2020 23:32:02 -0400, Bob Bridges wrote: > >o Well, maybe not on the first one: What's "TOCTTOU"? > GIYF. It's my habit to verify initialisms before I use them. >o Access rules are indeed complicated to simulate. > ... >o Of course the rules are subject to change. I can't see that that makes any > difference, makes it any less handy to know what the rules are. If he takes > your advice (just try the access and report the failure), the rule may > ~still~ > change; so what? > I'm thinking not of merely rule changes, but major structural changes. Do David's suggested Assembler and Rexx programs, LISTDSD, and CBT file 106 work alike for Classic data sets and for //SYSUT1 DD PATH=...? Did they work immediately when OMVS was introduced? (I've read that one of the ISV security products rapidly accommodated OMVS paths, but with the restriction that pathnames were limited to 44 characters(?!) and treated as case- insensitive.) >o I've never had occasion to try in it TSS or ACF2 - being a security jock, I > always ~have~ the elevated privileges, so I'm generally unaware of how they > behave for hoi polloi - but I know that it's possible even for regular folks > to use the RACF commands to determine whether they have read access to a > dataset. I don't know about update. > A security jock should treat an access query with a negative reply as a violation as serious as attempting the access and failing. In particular, a programmer scanning the catalog and querying access to every data set should be deemed a (fe)malefactor. There might be reason to protect querying access more strictly than actually attempting the access. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
On 13 Jun 2020 21:45:00 -0700, in bit.listserv.ibm-main (Message-ID:) dspiegel...@hotmail.com (David Spiegel) wrote: I am aware of CBT 106. I presented my solution in case the user wanted to know if s/he had access. If so, s/he could avoid all of the paperwork and permission required to change IKJTSOxx etc. (which is probably almost never granted). Multiple techniques and examples are good. I'm sorry if I sounded dismissive. But if you're running under TSO and just want to know your own access to a dataset, the LISTDSD command will tell you that. I had a REXX program to parse the output of LISTDSD and pull out just the "your access" information. It issued the command once with "discrete" and once with "generic" and gave full information. But the OP wanted to do it in Assembler, so this technique is moot. (Plus, I think they've added the capability to restrict that command since I retired.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
Hi Arthur, I am aware of CBT 106. I presented my solution in case the user wanted to know if s/he had access. If so, s/he could avoid all of the paperwork and permission required to change IKJTSOxx etc. (which is probably almost never granted). I had a job at a large bank and asked for IKJTSOxx to be changed, so that DFSMSdss could be invoked via Rexx/CLIST (interactively). To make a long story short, the head MVS guy refused. It seems as if some people are not aware of some of the theoretical aspects of Address Spaces and how each Address Space's Virtual Private Storage is actually private. Regards, David On 2020-06-14 00:31, Arthur wrote: On 13 Jun 2020 21:22:07 -0700, in bit.listserv.ibm-main (Message-ID:) dspiegel...@hotmail.com (David Spiegel) wrote: Here is my solution ... 1) An Assembler program ... Does not to be APF Authorized, if ESM is RACF. (If ESM is ACF/2 or TSS, it needs APF Authorization). Your program asks "Do I have access?" CBT file 106 needs to run authorized because it asks, "Does this *other* user have access?" The OPs question could be interpreted either way. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
On 13 Jun 2020 21:22:07 -0700, in bit.listserv.ibm-main (Message-ID:) dspiegel...@hotmail.com (David Spiegel) wrote: Here is my solution ... 1) An Assembler program ... Does not to be APF Authorized, if ESM is RACF. (If ESM is ACF/2 or TSS, it needs APF Authorization). Your program asks "Do I have access?" CBT file 106 needs to run authorized because it asks, "Does this *other* user have access?" The OPs question could be interpreted either way. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
Hi Colleagues, Here is my solution ... 1) An Assembler program ... Does not to be APF Authorized, if ESM is RACF. (If ESM is ACF/2 or TSS, it needs APF Authorization). 2) A Rexx Exec RACROUTE TITLE 'RACROUTE STATUS=ACCESS' RACROUTE CSECT , RACROUTE AMODE 31 RACROUTE RMODE ANY SAVE (14,12),,RACROUTE.&SYSDATE..&SYSTIME Save caller's regs. LR R12,R15 Load address of entry point USING RACROUTE,R12 Give assembler program's base reg. * LR R11,R1 Save Pointer to Parameter Address Blk USING ARGS,R11 * GETMAIN R,LV=SAVESIZE,LOC=BELOW XC 0(CLEARSIZ,R1),0(R1) Clear the save/work area ST R1,8(,R13) Save new save area addr.in old area ST R13,4(,R1) Save old save area addr.in new area LR R13,R1 Replace old save area with new one USING SAVEAREA,R13 Tell assembler about save area * * * L R11,0(R11) LH R5,0(R11) C R5,=F'0' PARM? BE RETURN No, RETURN * BCTR R5,0 EX R5,MVC B CONTINUE * MVC MVC THEENT(*-*),2(R11) * * * CONTINUE DS 0F RACROUTE REQUEST=AUTH, x RELEASE=1.9, x STATUS=ACCESS, x CLASS='DATASET', x ATTR=UPDATE, x ENTITY=THEENT,VOLSER=THEVOL, x WORKA=SAFWORKA LM R3,R4,CONTINUE+4 Save Return Code, Reason Code * * * RETURN DS 0H * WTO 'RACROUTE About to Exit' LR R1,R13 Save old save area addr. for FREEMAIN L R13,4(,R13) Restore old save area address FREEMAIN R,LV=SAVESIZE,A=(1) EXIT DS 0H LR R15,R4 Return with Reason Code * SLR R15,R15 Set a return code of zero RETURN (14,12),RC=(15) Return to caller, return code zero * * * DS 0D SAFWORKA DS CL512 THEENT DC CL44' ' THEVOL DC CL6'THEVOL' * * * SAVEAREA DSECT , Register save area and work area DS 18F Register save area CLEARSIZ EQU *-SAVEAREA Save and work area size RECORD DS 0CL16 USERID DS CL8 PASSWORD DS CL8 RECSIZE EQU *-RECORD WTO0 WTO ' ',X MF=L WTO0L EQU *-WTO0 SAVESIZE EQU *-SAVEAREA Save and work area size * * * ARGS DSECT DS 0D LENGTH DS H DSNAME DS CL44 Dataset Name to Check YREGS END /* Rexx */ /* Trace I */ /* 00 The user has no access. 04 The user has READ authority. 08 The user has UPDATE authority. 0C The user has CONTROL authority. 10 The user has ALTER authority https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos. v2r1.ichc600/ich2c6_Return_codes_and_reason_codes1.htm */ Arg dsn Address TSO "Call *(Racroute) '"dsn"'" Say rc On 2020-06-13 23:32, Bob Bridges wrote: Gil, you mustn't think I plan to make it a habit but I think I'm going to disagree with you on every point, here: o Well, maybe not on the first one: What's "TOCTTOU"? o Access rules are indeed complicated to simulate. But why simulate them? Just ask RACROUTE and get an answer. Mind you a) I'm a security geek, so maybe the rules seem less complicated to me. And b) I've never used RACROUTE directly; as a security geek I talk to RACF/ACF2/TSS through their TSO-level commands, so maybe RACROUTE is more difficult. o Of course the rules are subject to change. I can't see that that makes any difference, makes it any less handy to know what the rules are. If he takes your advice (just try the access and report the failure), the rule may ~still~ change; so what? o I've never had occasion to try in it TSS or ACF2 - being a security jock, I always ~have~ the elevated privileges, so I'm generally unaware of how they behave for hoi polloi - but I know that it's possible even for regular folks to use the RACF commands to determine whether they have read access to a dataset. I don't know about update. This question came up in TSO-REXX back in 2013, and I described how to do it and saved it away in case I wanted to use it again. I've sent it off-line to Mr DeChirico already; if anyone else wants to see it, just ask. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Never miss a good chance to shut up. -from A Cowboy's Guide to Life */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, June 13, 2020 22:09 Don't. o There's a TOCTTOU hazard. o The rules are probably too complicated to simulate. I'll add: o The rules are subject to change. o You may need elevated privilege even to perfor
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
Gil, you mustn't think I plan to make it a habit but I think I'm going to disagree with you on every point, here: o Well, maybe not on the first one: What's "TOCTTOU"? o Access rules are indeed complicated to simulate. But why simulate them? Just ask RACROUTE and get an answer. Mind you a) I'm a security geek, so maybe the rules seem less complicated to me. And b) I've never used RACROUTE directly; as a security geek I talk to RACF/ACF2/TSS through their TSO-level commands, so maybe RACROUTE is more difficult. o Of course the rules are subject to change. I can't see that that makes any difference, makes it any less handy to know what the rules are. If he takes your advice (just try the access and report the failure), the rule may ~still~ change; so what? o I've never had occasion to try in it TSS or ACF2 - being a security jock, I always ~have~ the elevated privileges, so I'm generally unaware of how they behave for hoi polloi - but I know that it's possible even for regular folks to use the RACF commands to determine whether they have read access to a dataset. I don't know about update. This question came up in TSO-REXX back in 2013, and I described how to do it and saved it away in case I wanted to use it again. I've sent it off-line to Mr DeChirico already; if anyone else wants to see it, just ask. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Never miss a good chance to shut up. -from A Cowboy's Guide to Life */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, June 13, 2020 22:09 Don't. o There's a TOCTTOU hazard. o The rules are probably too complicated to simulate. I'll add: o The rules are subject to change. o You may need elevated privilege even to perform the check. Better just to try the access and report any failure. >--- On Sat, 13 Jun 2020 09:10:01 -0700 (PDT), Michael DeChirico wrote: >>Are there any hlasm code examples on how to user RACROUTE >>to verify a userid's access to read/write a dataset? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
On Sat, 13 Jun 2020 16:58:52 -0400, Arthur wrote: >On Sat, 13 Jun 2020 09:10:01 -0700 (PDT), Michael DeChirico wrote: > >>Are there any hlasm code examples on how to user RACROUTE >>to verify a userid's access to read/write a dataset? > It has been written here by Walt Farrell, among others: Don't. o There's a TOCTTOU hazard. o The rules are probably too complicated to simulate. I'll add: o The rules are subject to change. o You may need elevated privilege even to perform the check. Better just to try the access and report any failure. >Check CBT file 106: >http://www.cbttape.org/ftp/cbt/CBT106.zip > >There are examples of almost everything on CBT. > >Also, join the Listserv. Most of the people here will not >have seen your original question. For information on how, >see the bottom of just about any message here (including >this one). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
On Sat, 13 Jun 2020 09:10:01 -0700 (PDT), in bit.listserv.ibm-main (Message-ID:) Michael DeChirico wrote: Are there any hlasm code examples on how to user RACROUTE to verify a userid's access to read/write a dataset? Check CBT file 106: http://www.cbttape.org/ftp/cbt/CBT106.zip There are examples of almost everything on CBT. Also, join the Listserv. Most of the people here will not have seen your original question. For information on how, see the bottom of just about any message here (including this one). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
