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 security problem with a person asking, I guess I have to agree, after all, that it's better to just attempt it and handle the failure. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* ...I instinctively sympathize with people who refuse to be bullied into conformity with the Latest Thing. I admire the reactionary Catholic, the Orthodox Jew, the fundamentalist Protestant, the Mormon, the die-hard Confederate -- anyone who has the guts to prefer a tradition to a compulsory modern fashion. I may disagree with him, but at least I know he's not made of jelly. His inner life resists external pressure. / I profoundly disagree with Abraham Lincoln, but I respect Lincoln for arguing like a man. He never tried to win a debate with vacuous name-calling. He appealed not to trendy slogans, but to permanent truths. That's why his arguments are still interesting....Right or wrong, those arguments issue from the depths of a real mind, not the partisan impulses of a mere sect. -Joseph Sobran, 2001-05-10 */ >--- 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
