HOW DO I VERIFY A USERID'S ACCESS TO A DATASET

Discussion:

(too old to reply)

Michael DeChirico

2020-06-13 16:10:01 UTC

Hi

Are there any hlasm code examples on how to user RACROUTE to verify a userid's access to read/write a dataset?

Thanks

JD

Paul Gilmartin

2020-06-14 02:08:53 UTC

Permalink

Post by Michael DeChirico
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.

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Bob Bridges

2020-06-14 03:32:21 UTC

Permalink

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, ***@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-***@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.

Post by Michael DeChirico
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

David Spiegel

2020-06-14 04:22:07 UTC

Permalink

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

Post by Bob Bridges
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.
---
/* Never miss a good chance to shut up. -from A Cowboy's Guide to Life */
-----Original Message-----
Sent: Saturday, June 13, 2020 22:09
Don't.
o There's a TOCTTOU hazard.
o The rules are probably too complicated to simulate.
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.

Post by Michael DeChirico
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,
.

Bob Bridges

2020-06-14 19:51:35 UTC

Permalink

Further comments below.

-----Original Message-----
From: Bob Bridges [mailto:***@gmail.com]
Sent: Saturday, June 13, 2020 23:32

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@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, ***@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 */

Post by Michael DeChirico
Are there any hlasm code examples on how to user RACROUTE
to verify a userid's access to read/write a dataset?

Arthur

2020-06-14 04:31:42 UTC

Permalink

On 13 Jun 2020 21:22:07 -0700, in bit.listserv.ibm-main

Post by David Spiegel
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

David Spiegel

2020-06-14 04:45:00 UTC

Permalink

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

Post by Arthur
On 13 Jun 2020 21:22:07 -0700, in bit.listserv.ibm-main

Post by David Spiegel
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,
.

Arthur

2020-06-14 07:23:48 UTC

Permalink

On 13 Jun 2020 21:45:00 -0700, in bit.listserv.ibm-main

Post by David Spiegel
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Paul Gilmartin

2020-06-14 15:28:29 UTC

Permalink

Post by Bob Bridges
o Well, maybe not on the first one: What's "TOCTTOU"?

GIYF. It's my habit to verify initialisms before I use them.

Post by Bob Bridges
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.)

Post by Bob Bridges
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Paul Gilmartin

2020-06-14 21:55:45 UTC

Permalink

Post by Bob Bridges
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?

Post by Bob Bridges
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.

Post by Bob Bridges
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.

Seymour J Metz

2020-06-15 20:18:01 UTC

Permalink

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-***@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f07816-dmarc-***@LISTSERV.UA.EDU]
Sent: Sunday, June 14, 2020 5:55 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Arthur

2020-06-15 01:24:01 UTC

Permalink

On 14 Jun 2020 14:55:45 -0700, in bit.listserv.ibm-main

Post by Paul Gilmartin

Post by Bob Bridges
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Peter Relson

2020-06-15 12:22:06 UTC

Permalink

<snip>
A security jock should treat an access query with a negative reply as a
violation as serious as attempting the access and failing.
</snip>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Seymour J Metz

2020-06-15 17:08:57 UTC

Permalink

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-***@LISTSERV.UA.EDU] on behalf of Peter Relson [***@US.IBM.COM]
Sent: Monday, June 15, 2020 8:21 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET

<snip>
A security jock should treat an access query with a negative reply as a
violation as serious as attempting the access and failing.
</snip>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Sam Golob

2020-06-15 15:40:42 UTC

Permalink

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Walt Farrell

2020-06-20 23:09:42 UTC

Permalink

Post by Bob Bridges
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.

Post by Bob Bridges
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Paul Gilmartin

2020-06-21 14:55:10 UTC

Permalink

Post by Walt Farrell
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN