Discussion:
ATTACH with RSAPF=YES
Add Reply
Robin Atwood
2017-05-15 08:17:48 UTC
Reply
Permalink
Raw Message
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which

runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly what
I want but every time I try it

I get abend S306-0C, "authorised program attaching module from an
unauthorized library". The ATTACH macro

description states:



RSAPF=YES when these conditions are met:

. The caller is running in supervisor state, system key (0-7),
or both

. The caller is running non-APF authorized

. The subtask is attached in the problem program state and with
a nonsystem key.



Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP
and adding SM=PROB,KEY=PROP

to the ATTACH but it made no difference. I seem to be missing something
fairly massive here! Can anyone shed

some light on this?



Thanks

Robin


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Greg Dyck
2017-05-15 12:29:39 UTC
Reply
Permalink
Raw Message
Be aware that what you are attempting to do is dangerous and has the
potential to create system integrity exposures that would allow a
problem state program to cause a system failure. I am not saying that
it can not be done safely, because it can be. But to do it safely
without creating a system integrity exposure requires a lot more than
just using RSAPF=YES on the ATTACH.
Post by Robin Atwood
Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP
and adding SM=PROB,KEY=PROP
to the ATTACH but it made no difference. I seem to be missing something
fairly massive here! Can anyone shed some light on this?
You need to get into key 0 and reset JSCBAUTH prior to issuing the
ATTACH in order to meet qualification #2 below for RSAPF=YES to be
performed, and the ATTACH must then be issued in either a system key or
supervisor state (or both)-

RSAPF=YES when these conditions are met:
- The caller is running in supervisor state, system key (0-7), or
both
- The caller is running non-APF authorized
- The subtask is attached in the problem program state and with a
non-system key.

Regards, Greg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-05-15 12:37:38 UTC
Reply
Permalink
Raw Message
Post by Greg Dyck
Be aware that what you are attempting to do is dangerous and has the
potential to create system integrity exposures that would allow a problem
state program to cause a system failure. I am not saying that it can not
be done safely, because it can be. But to do it safely without creating a
system integrity exposure requires a lot more than just using RSAPF=YES on
the ATTACH.
Post by Robin Atwood
Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP
and adding SM=PROB,KEY=PROP
to the ATTACH but it made no difference. I seem to be missing something
fairly massive here! Can anyone shed some light on this?
​<snip>
Regards, Greg
​Just coming out of left field here. I don't know what the OP is trying to
accomplish (at a high level) by doing this. But in the context were I need
differing security attributes (such as APF), I would go with a UNIX fork().
Of course, if the ATTACH'd program needs to communicate with the parent
through shared memory, that complicates things a bit. But should be
possible using the z/OS shared memory API.​ Or my "marshalling" the data
and using some IPC such as pipe or, better, UNIX messages. The problem with
all this is the CPU overhead and complexity.
--
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2017-05-15 13:55:04 UTC
Reply
Permalink
Raw Message
Well, if you want to run unauthorized stuff you would first need to set your
job as non-APF by resetting the bit.

Of course, your authorized key8 storage will be subject to change by the
unauthorized task, thus your authorized code must not use Key8 storage.

(1) and (2) are not exclusive, as your authorized task would need to remain in
supervisor state after resetting APF (assuming you still need APF services).
If you no longer need APF services, simply reset APF do MODESET PROB and the
garden variety ATTACH(X)

Why do you want to run unauthorized code from this STC? What is the business
case?

On Mon, 15 May 2017 15:18:38 +0700 Robin Atwood <***@GMAIL.COM> wrote:

:>We have a requirement to attach user modules from an unauthorised library
:>and execute them from an STC which
:>
:>runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly what
:>I want but every time I try it
:>
:>I get abend S306-0C, "authorised program attaching module from an
:>unauthorized library". The ATTACH macro
:>
:>description states:
:>
:>
:>
:>RSAPF=YES when these conditions are met:
:>
:>. The caller is running in supervisor state, system key (0-7),
:>or both
:>
:>. The caller is running non-APF authorized
:>
:>. The subtask is attached in the problem program state and with
:>a nonsystem key.
:>
:>
:>
:>Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP
:>and adding SM=PROB,KEY=PROP
:>
:>to the ATTACH but it made no difference. I seem to be missing something
:>fairly massive here! Can anyone shed
:>
:>some light on this?
:>
:>
:>
:>Thanks
:>
:>Robin
:>
:>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-16 07:08:59 UTC
Reply
Permalink
Raw Message
Thanks to everyone for replying, I would never realised you had to flip
JSCBAUTH from the macro documentation.
The actual business requirement is that we run Rexx execs that call ISPF
services on behalf of workstation users
running an IDE. The STC doing this must run authorised because it
communicates with a comms task via cross-memory services. So we will have
control over what gets executed. This is still very much an experiment, I am
not
sure it will actually work.

Thanks
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: 15 May 2017 20:56
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

Well, if you want to run unauthorized stuff you would first need to set your
job as non-APF by resetting the bit.

Of course, your authorized key8 storage will be subject to change by the
unauthorized task, thus your authorized code must not use Key8 storage.

(1) and (2) are not exclusive, as your authorized task would need to remain
in supervisor state after resetting APF (assuming you still need APF
services).
If you no longer need APF services, simply reset APF do MODESET PROB and the
garden variety ATTACH(X)

Why do you want to run unauthorized code from this STC? What is the business
case?

On Mon, 15 May 2017 15:18:38 +0700 Robin Atwood <***@GMAIL.COM> wrote:

:>We have a requirement to attach user modules from an unauthorised library
:>and execute them from an STC which :> :>runs APF authorised. Calling
ATTACH with RSAPF=YES seems to do exactly what :>I want but every time I try
it :> :>I get abend S306-0C, "authorised program attaching module from an
:>unauthorized library". The ATTACH macro :> :>description states:
:>
:>
:>
:>RSAPF=YES when these conditions are met:
:>
:>. The caller is running in supervisor state, system key (0-7),
:>or both
:>
:>. The caller is running non-APF authorized
:>
:>. The subtask is attached in the problem program state and
with
:>a nonsystem key.
:>
:>
:>
:>Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET
MODE=SUP :>and adding SM=PROB,KEY=PROP :> :>to the ATTACH but it made no
difference. I seem to be missing something :>fairly massive here! Can anyone
shed :> :>some light on this?
:>
:>
:>
:>Thanks
:>
:>Robin
:>
:>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions, :>send
email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen <***@dissensoftware.com> http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me, you
should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems, especially
those from irresponsible companies.

----------------------------------------------------------------------
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
Charles Mills
2017-05-16 12:40:32 UTC
Reply
Permalink
Raw Message
So we will have control over what gets executed
As others have pointed out, you are exposing yourself to risks that you will
have to manage. MVS would be willing to take on some of that management for
you, but you are overriding that facility.

You need to make absolutely sure of who has the ability to write into every
single dataset used as a load or parameter or script library by every single
thing called by your STC.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Robin Atwood
Sent: Tuesday, May 16, 2017 12:10 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

Thanks to everyone for replying, I would never realised you had to flip
JSCBAUTH from the macro documentation.
The actual business requirement is that we run Rexx execs that call ISPF
services on behalf of workstation users running an IDE. The STC doing this
must run authorised because it communicates with a comms task via
cross-memory services. So we will have control over what gets executed. This
is still very much an experiment, I am not sure it will actually work.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-05-15 14:15:34 UTC
Reply
Permalink
Raw Message
Post by Robin Atwood
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which
runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly what
I want ...
It _can_ do what you want, Robin, but as others have said it is very risky to do this, and very complex to do it safely. Basically, what you're trying will only work safely if your STC is designed properly to allow it. At a minimum, I believe that means making sure that none of your STC code runs in key 8 or uses key 8 storage. It would need to start from the beginning in a system key, specified by the Program Properties Table in PARMLIB. You could then, possibly, invoke the non-APF code safely as long as you run it in key 8.

But the question then becomes what do you expect the non-APF code to do, and how do you expect to communicate with it.

It really would be better and safer, in my opinion, to find another solution. This might possibly involve using multiple address spaces (via UNIX fork()) as John McKown suggested. But we would really need to know a lot more information about your STC, and the non-APF code, to be able to provide the best advice.

(It is very unlikely, in my experience, that your current STC is designed to allow you to do this safely. A major redesign and reimplementation of the STC would probably be required if you haven't been thinking about this from the very beginning of its development.)
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2017-05-15 14:27:43 UTC
Reply
Permalink
Raw Message
RSAPF probably shouldn't even be documented. AFAIK, it's only purpose is
to allow the system to support unauthorized tasks and jobs, and is used
only with the creation of a new job-step task. And there is no
communication between the initiator task and the user task.

Authorized programs aren't allowed to invoke unauthorized code for a very
good reason. Trying to circumvent that in any way compromises your system
integrity. That said, running bad authorized code does as well, so caveat
emptor.

sas
Post by Walt Farrell
Post by Robin Atwood
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which
runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly
what
Post by Robin Atwood
I want ...
It _can_ do what you want, Robin, but as others have said it is very risky
to do this, and very complex to do it safely. Basically, what you're trying
will only work safely if your STC is designed properly to allow it. At a
minimum, I believe that means making sure that none of your STC code runs
in key 8 or uses key 8 storage. It would need to start from the beginning
in a system key, specified by the Program Properties Table in PARMLIB. You
could then, possibly, invoke the non-APF code safely as long as you run it
in key 8.
But the question then becomes what do you expect the non-APF code to do,
and how do you expect to communicate with it.
It really would be better and safer, in my opinion, to find another
solution. This might possibly involve using multiple address spaces (via
UNIX fork()) as John McKown suggested. But we would really need to know a
lot more information about your STC, and the non-APF code, to be able to
provide the best advice.
(It is very unlikely, in my experience, that your current STC is designed
to allow you to do this safely. A major redesign and reimplementation of
the STC would probably be required if you haven't been thinking about this
from the very beginning of its development.)
--
Walt
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-05-15 16:06:02 UTC
Reply
Permalink
Raw Message
At a long-gone bank, we ran IBM's check processing application CPCS, which needed to run APF authorized. This meant that any program called by CPCS needed to come from an APF library. For whatever reason, CPCS invoked standard utilities such as DFSORT, which meant that those libraries also had to be APF just so the programs could be called by CPCS.

We learned at some point about the possibility of flipping JSCBAUTH to tweak the APF mode. But CPCS was a multitasking application that was doing lots of things concurrently. There is only one JSCBAUTH flag. If turned it off for, say, SORT processing, we would very likely kill some other subtask that needed APF on. We decided that was pretty much impossible to manage. So everything that ran within CPCS came from an APF library. Note that individual programs do not need APF=1, but the library needs to be in APF list.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Steve Smith
Sent: Monday, May 15, 2017 7:29 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: ATTACH with RSAPF=YES

RSAPF probably shouldn't even be documented. AFAIK, it's only purpose is to allow the system to support unauthorized tasks and jobs, and is used only with the creation of a new job-step task. And there is no communication between the initiator task and the user task.

Authorized programs aren't allowed to invoke unauthorized code for a very good reason. Trying to circumvent that in any way compromises your system integrity. That said, running bad authorized code does as well, so caveat emptor.

sas
Post by Walt Farrell
Post by Robin Atwood
We have a requirement to attach user modules from an unauthorised
library and execute them from an STC which
runs APF authorised. Calling ATTACH with RSAPF=YES seems to do
exactly
what
Post by Robin Atwood
I want ...
It _can_ do what you want, Robin, but as others have said it is very
risky to do this, and very complex to do it safely. Basically, what
you're trying will only work safely if your STC is designed properly
to allow it. At a minimum, I believe that means making sure that none
of your STC code runs in key 8 or uses key 8 storage. It would need to
start from the beginning in a system key, specified by the Program
Properties Table in PARMLIB. You could then, possibly, invoke the
non-APF code safely as long as you run it in key 8.
But the question then becomes what do you expect the non-APF code to
do, and how do you expect to communicate with it.
It really would be better and safer, in my opinion, to find another
solution. This might possibly involve using multiple address spaces
(via UNIX fork()) as John McKown suggested. But we would really need
to know a lot more information about your STC, and the non-APF code,
to be able to provide the best advice.
(It is very unlikely, in my experience, that your current STC is
designed to allow you to do this safely. A major redesign and
reimplementation of the STC would probably be required if you haven't
been thinking about this from the very beginning of its development.)
--
Walt
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-05-15 16:27:09 UTC
Reply
Permalink
Raw Message
Post by Steve Smith
RSAPF probably shouldn't even be documented. AFAIK, it's only purpose is
to allow the system to support unauthorized tasks and jobs, and is used
only with the creation of a new job-step task. And there is no
communication between the initiator task and the user task.
What does the TSO TMP use to accomplish this?

(Topic drift: What's the difference between INTRDR and TSOINRDR?)
Post by Steve Smith
Authorized programs aren't allowed to invoke unauthorized code for a very
good reason. Trying to circumvent that in any way compromises your system
integrity. That said, running bad authorized code does as well, so caveat
emptor.
A couple contributors have suggested fork(). A similar option is BPX1EXM.
But all such facilities introduce complexities in communication between
parent and child processes.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Greg Dyck
2017-05-15 16:45:13 UTC
Reply
Permalink
Raw Message
Post by Paul Gilmartin
What does the TSO TMP use to accomplish this?
Extreme care ;-)

It has been a while, but my memory is that the TMP stops all of the
tasks above (or is that below?) it in the task tree and then passes the
request to a special jobstep task (with it's own JSCB) to execute the
command.

Regards,
Greg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Shaw
2017-05-15 17:18:39 UTC
Reply
Permalink
Raw Message
Post by Greg Dyck
Post by Paul Gilmartin
What does the TSO TMP use to accomplish this?
Extreme care ;-)
It has been a while, but my memory is that the TMP stops all of the
tasks above (or is that below?) it in the task tree and then passes the
request to a special jobstep task (with it's own JSCB) to execute the
command.
Regards,
Greg
Greg is correct; IKJEFT02 and its subtasks are STATUS STOP'ed, and a new
parallel (sister) task is attached to invoke anything needing APF
authorization. The TSO/E TSOEXEC command exists to do just that.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-05-16 13:14:17 UTC
Reply
Permalink
Raw Message
Post by Robin Atwood
Thanks to everyone for replying, I would never realised you had to flip
JSCBAUTH from the macro documentation.
The actual business requirement is that we run Rexx execs that call ISPF
services on behalf of workstation users
running an IDE. The STC doing this must run authorised because it
communicates with a comms task via cross-memory services. So we will have
control over what gets executed. This is still very much an experiment, I am
not sure it will actually work.
Technically, for the communication you've described, only the comms task would have to run authorized. The STC could run unauthorized, using mechanisms setup by the authorized comms task.

However, as you're running work on behalf of various end-users, I hope you're authenticating those users and running the work under the proper end-user identity in each case. And that would probably require authorization of the STC.

It is a very tricky situation to manage properly and without introducing either system integrity or security issues.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-16 13:41:51 UTC
Reply
Permalink
Raw Message
However, as you're running work on behalf of various end-users, I hope you're authenticating those users and >running the work under the proper end-user identity in each case. And that would probably require authorization >of the STC.
Yes, we run under the ACEE of the user.

Robin

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-05-16 13:57:45 UTC
Reply
Permalink
Raw Message
<snip>
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which runs APF authorised.
</snip>

You need to reject that requirement. It cannot be accomplished while
maintaining system integrity. Use of something like "fork" can perhaps
accomplish the goal without meeting the letter of the requirement.

<snip>
Well, if you want to run unauthorized stuff you would first need to set
your
job as non-APF by resetting the bit.
</snip>

And if you do that, you must *never* turn the bit back on. Turning of
JSCBAUTH is a fairly common approach, once the "authorized stuff" has been
done. But you must then leave it off in order to maintain system
integrity.

In all likelihood you should NEVER use RSAPF=YES. It is provided so that
the initiator can attach the jobstep program task. I have no idea why it
was documented. Way back when, even internal things were documented. Maybe
when internal-only things were being removed from the books, no one
realized how internal this one was.

The only z/OS-supported mechanism for authority-decreasing is SYNCH(X).
And I do intentionally exclude authority-decreasing PC's (e.g., a PC that
gets control in problem state when the invoker was supervisor state) from
what is supported by z/OS. You can't be stopped from doing so, but things
likely won't behave the way you need if there was a (E)SPIE present. There
might be cases other than (E)SPIE that similarly would cause anomalous
behavior. I have no idea if this is documented explicitly. It's just
something I remember being told long long ago.

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
Robin Atwood
2017-05-17 07:34:40 UTC
Reply
Permalink
Raw Message
Peter-
Thanks for this, I shall ponder.

Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: 16 May 2017 20:58
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

<snip>
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which runs APF authorised.
</snip>

You need to reject that requirement. It cannot be accomplished while
maintaining system integrity. Use of something like "fork" can perhaps
accomplish the goal without meeting the letter of the requirement.

<snip>
Well, if you want to run unauthorized stuff you would first need to set your
job as non-APF by resetting the bit.
</snip>

And if you do that, you must *never* turn the bit back on. Turning of
JSCBAUTH is a fairly common approach, once the "authorized stuff" has been
done. But you must then leave it off in order to maintain system integrity.

In all likelihood you should NEVER use RSAPF=YES. It is provided so that the
initiator can attach the jobstep program task. I have no idea why it was
documented. Way back when, even internal things were documented. Maybe when
internal-only things were being removed from the books, no one realized how
internal this one was.

The only z/OS-supported mechanism for authority-decreasing is SYNCH(X).
And I do intentionally exclude authority-decreasing PC's (e.g., a PC that
gets control in problem state when the invoker was supervisor state) from
what is supported by z/OS. You can't be stopped from doing so, but things
likely won't behave the way you need if there was a (E)SPIE present. There
might be cases other than (E)SPIE that similarly would cause anomalous
behavior. I have no idea if this is documented explicitly. It's just
something I remember being told long long ago.

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
Robin Atwood
2017-05-18 12:55:39 UTC
Reply
Permalink
Raw Message
What is the situation of a module that is loaded from an authorised library
but was linked with AC=0? Is it authorised? Can it get authorised?

Thanks
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: 16 May 2017 20:58
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

<snip>
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which runs APF authorised.
</snip>

You need to reject that requirement. It cannot be accomplished while
maintaining system integrity. Use of something like "fork" can perhaps
accomplish the goal without meeting the letter of the requirement.

<snip>
Well, if you want to run unauthorized stuff you would first need to set your
job as non-APF by resetting the bit.
</snip>

And if you do that, you must *never* turn the bit back on. Turning of
JSCBAUTH is a fairly common approach, once the "authorized stuff" has been
done. But you must then leave it off in order to maintain system integrity.

In all likelihood you should NEVER use RSAPF=YES. It is provided so that the
initiator can attach the jobstep program task. I have no idea why it was
documented. Way back when, even internal things were documented. Maybe when
internal-only things were being removed from the books, no one realized how
internal this one was.

The only z/OS-supported mechanism for authority-decreasing is SYNCH(X).
And I do intentionally exclude authority-decreasing PC's (e.g., a PC that
gets control in problem state when the invoker was supervisor state) from
what is supported by z/OS. You can't be stopped from doing so, but things
likely won't behave the way you need if there was a (E)SPIE present. There
might be cases other than (E)SPIE that similarly would cause anomalous
behavior. I have no idea if this is documented explicitly. It's just
something I remember being told long long ago.

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
Charles Mills
2017-05-18 15:08:22 UTC
Reply
Permalink
Raw Message
Tom answered most of your question but in addition
Post by Robin Atwood
Can it get authorised?
I don't think there is any supported way for a program that is already
running to "get authorized."

I hope you are getting the idea how risky this entire approach is. You are
playing "you bet your mainframe." You might get it right today but what
happens five years from now (that's not very long. Remember 2012?) when you
have moved to other responsibilities, there is a new RACF administrator who
does not understand all the ramifications of your process, etc., etc.?

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Robin Atwood
Sent: Thursday, May 18, 2017 5:56 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

What is the situation of a module that is loaded from an authorised library
but was linked with AC=0? Is it authorised? Can it get authorised?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Harminc
2017-05-18 16:22:25 UTC
Reply
Permalink
Raw Message
Post by Robin Atwood
What is the situation of a module that is loaded from an authorised library
but was linked with AC=0? Is it authorised? Can it get authorised?
Modules are not authorized. Job steps are authorized.

If you are able to get your job step from an unauthorized to an authorized
state using IBM supplied facilities, IBM promises to fix it so you can't.
And probably pretty quickly.

I don't mean to sound pedantic about this. There is indeed an important
distinction between modules marked AC(1) and those not, when they live in
an authorized library. Nothing prevents an AC(0) module from being loaded
from such a library by an authorized job step, and given control in an
authorized state. This is the normal situation. The only modules that
should be marked AC(1) are those that are intended to be invoked as the
initial program of a job step, which typically means EXEC PGM= in JCL, or
CALL in TSO. (TSO has additional requirements to make CALL invoke a program
in an authorized state.) Such modules must be prepared to deal safely with
their environment, parms, and input data and not compromise system
integrity, because any user can invoke them with any parms and input.
Modules that are intended to run authorized, but to be invoked only by
other code running authorized, may not need such general protection against
malicious invokers.

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-19 07:08:40 UTC
Reply
Permalink
Raw Message
I thought this must be the case but wanted to check. This is indeed how the product I am working on is set up: the
top-level job step module is AC=1, the rest not.

Thanks
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
Sent: 18 May 2017 23:23
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
Post by Robin Atwood
What is the situation of a module that is loaded from an authorised
library but was linked with AC=0? Is it authorised? Can it get authorised?
Modules are not authorized. Job steps are authorized.

If you are able to get your job step from an unauthorized to an authorized state using IBM supplied facilities, IBM promises to fix it so you can't.
And probably pretty quickly.

I don't mean to sound pedantic about this. There is indeed an important distinction between modules marked AC(1) and those not, when they live in an authorized library. Nothing prevents an AC(0) module from being loaded from such a library by an authorized job step, and given control in an authorized state. This is the normal situation. The only modules that should be marked AC(1) are those that are intended to be invoked as the initial program of a job step, which typically means EXEC PGM= in JCL, or CALL in TSO. (TSO has additional requirements to make CALL invoke a program in an authorized state.) Such modules must be prepared to deal safely with their environment, parms, and input data and not compromise system integrity, because any user can invoke them with any parms and input.
Modules that are intended to run authorized, but to be invoked only by other code running authorized, may not need such general protection against malicious invokers.

Tony H.

----------------------------------------------------------------------
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
Walt Farrell
2017-05-16 15:32:09 UTC
Reply
Permalink
Raw Message
Post by Robin Atwood
However, as you're running work on behalf of various end-users, I hope you're authenticating those users and >running the work under the proper end-user identity in each case. And that would probably require authorization >of the STC.
Yes, we run under the ACEE of the user.
However, unless your STC runs single-threaded (handling requests for only 1 user at a time) it's not possible for you to run REXX execs invokiing ISPF services with proper security.

It would require ensuring that none of the execs, or the services they invoke, perform any ATTACH requests., The new subtask created by ATTACH would not inherit the ACEE of the user on whose behalf you're running the request. (There is one exception to that, but it's used rarely enough that it probably won't apply to you. You would have to be using WLM services, and operating as a WLM servant to manage the requests that you're processing. Then, and only then as far as I know, would the user's ACEE propagate down to a new subtask.)
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-17 07:26:37 UTC
Reply
Permalink
Raw Message
We set the ASXBSENV to the ACEE of the user. The requests are run single-threaded, we will have a pool of STCs
available.

Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Walt Farrell
Sent: 16 May 2017 22:33
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
Post by Robin Atwood
However, as you're running work on behalf of various end-users, I hope you're authenticating those users and >running the work under the proper end-user identity in each case. And that would probably require authorization >of the STC.
Yes, we run under the ACEE of the user.
However, unless your STC runs single-threaded (handling requests for only 1 user at a time) it's not possible for you to run REXX execs invokiing ISPF services with proper security.

It would require ensuring that none of the execs, or the services they invoke, perform any ATTACH requests., The new subtask created by ATTACH would not inherit the ACEE of the user on whose behalf you're running the request. (There is one exception to that, but it's used rarely enough that it probably won't apply to you. You would have to be using WLM services, and operating as a WLM servant to manage the requests that you're processing. Then, and only then as far as I know, would the user's ACEE propagate down to a new subtask.)

--
Walt

----------------------------------------------------------------------
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
Binyamin Dissen
2017-05-17 11:59:11 UTC
Reply
Permalink
Raw Message
In which case you should supply two calls to the non-privileged STC, one which
will get the work element and set the security and a second which will return
results. The calls can be PC's or SVCs.

On Wed, 17 May 2017 14:27:25 +0700 Robin Atwood <***@GMAIL.COM> wrote:

:>We set the ASXBSENV to the ACEE of the user. The requests are run single-threaded, we will have a pool of STCs
:>available.
:>
:>Robin
:>
:>-----Original Message-----
:>From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Walt Farrell
:>Sent: 16 May 2017 22:33
:>To: IBM-***@LISTSERV.UA.EDU
:>Subject: Re: ATTACH with RSAPF=YES
:>
:>On Tue, 16 May 2017 20:42:42 +0700, Robin Atwood <***@GMAIL.COM> wrote:
:>
:>>>However, as you're running work on behalf of various end-users, I hope you're authenticating those users and >running the work under the proper end-user identity in each case. And that would probably require authorization >of the STC.
:>>
:>>Yes, we run under the ACEE of the user.
:>
:>However, unless your STC runs single-threaded (handling requests for only 1 user at a time) it's not possible for you to run REXX execs invokiing ISPF services with proper security.
:>
:>It would require ensuring that none of the execs, or the services they invoke, perform any ATTACH requests., The new subtask created by ATTACH would not inherit the ACEE of the user on whose behalf you're running the request. (There is one exception to that, but it's used rarely enough that it probably won't apply to you. You would have to be using WLM services, and operating as a WLM servant to manage the requests that you're processing. Then, and only then as far as I know, would the user's ACEE propagate down to a new subtask.)

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-05-18 13:55:02 UTC
Reply
Permalink
Raw Message
Post by Robin Atwood
What is the situation of a module that is loaded from an authorised library
but was linked with AC=0? Is it authorised? Can it get authorised?
Loaded by whom?

When you EXEC PGM=x, if program X is linked AC=1 and is loaded from
an APF authorized library, and all JOBLIB/STEPLIB libraries are APF
authorized, the address space is authorized.

If program X, running in an authorized address space loads program Y,
it does not matter whether program Y is linked AC=0 or AC=1. It must
come from an APF authorized library. The address space is still authorized.
The system can't tell when control passes between program X and
program Y.

This simplified version of what happens is basic APF authorization stuff.
I would expect that anyone who wants to do what you propose would
have a thorough understanding of this.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-05-18 15:57:26 UTC
Reply
Permalink
Raw Message
Early versions of SDSF provided an SVC that would make the user authorized. It was 'supported' in that it was part of an official IBM program product. There was a general discomfort with this strategy even though the SVC code tried very hard to validate the environment. Eventually (I believe) the SVC was discarded as being too difficult to make airtight.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Thursday, May 18, 2017 8:09 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: ATTACH with RSAPF=YES

Tom answered most of your question but in addition
Post by Robin Atwood
Can it get authorised?
I don't think there is any supported way for a program that is already running to "get authorized."

I hope you are getting the idea how risky this entire approach is. You are playing "you bet your mainframe." You might get it right today but what happens five years from now (that's not very long. Remember 2012?) when you have moved to other responsibilities, there is a new RACF administrator who does not understand all the ramifications of your process, etc., etc.?

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Robin Atwood
Sent: Thursday, May 18, 2017 5:56 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

What is the situation of a module that is loaded from an authorised library but was linked with AC=0? Is it authorised? Can it get authorised?


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-05-18 16:18:31 UTC
Reply
Permalink
Raw Message
"Magic" SVCs are the scourge of z/OS integrity.

The amount of validation you have to do to make a magic SVC airtight exceeds the burden of simply doing it right: linking the program AC=1 into an APF-authorized library.

They used to be common in vendor products: easier to write a magic SVC than to get the customer to authorize the library. I think the practice is on the decline.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Thursday, May 18, 2017 8:58 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

Early versions of SDSF provided an SVC that would make the user authorized. It was 'supported' in that it was part of an official IBM program product. There was a general discomfort with this strategy even though the SVC code tried very hard to validate the environment. Eventually (I believe) the SVC was discarded as being too difficult to make airtight.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-05-18 18:46:49 UTC
Reply
Permalink
Raw Message
Post by Charles Mills
I hope you are getting the idea how risky this entire approach is. You are
playing "you bet your mainframe." You might get it right today....
And if you don't get it right, you might discover that, or you might not.
It is very difficult to demonstrate that you have not created an integrity exposure.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-19 07:31:40 UTC
Reply
Permalink
Raw Message
The situation would be that the client routes a command to the server on the host which routes it to a dependent ASID. The DA gets the ACEE of the user and executes the command via IJKEFTSR. The command is one of a suite of
Rexx execs in a library allocated to the DA which executes ISPF services (eg, to copy some members). Without wilful
collaboration of a sysprog I am struggling to see how this could be subverted by a malicious user. However, if you can see something please let me know!

Thanks
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tom Marchant
Sent: 19 May 2017 01:47
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
Post by Charles Mills
I hope you are getting the idea how risky this entire approach is. You
are playing "you bet your mainframe." You might get it right today....
And if you don't get it right, you might discover that, or you might not.
It is very difficult to demonstrate that you have not created an integrity exposure.

--
Tom Marchant

----------------------------------------------------------------------
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
Walt Farrell
2017-05-19 12:33:03 UTC
Reply
Permalink
Raw Message
Post by Robin Atwood
The situation would be that the client routes a command to the server on the host which routes it to a dependent ASID. The DA gets the ACEE of the user and executes the command via IJKEFTSR. The command is one of a suite of
Rexx execs in a library allocated to the DA which executes ISPF services (eg, to copy some members). Without wilful
collaboration of a sysprog I am struggling to see how this could be subverted by a malicious user. However, if you can see something >please let me know!
It all comes down to the fine (and unknown to us) details of how your dependent ASID initializes, what storage key the initiator ATTACHes it in, what storage keys it uses, and how you plan to remove authorization (JSCBAUTH) before invoking IKJEFTSR. (And that you never restore authorization (JSCBAUTH) once you've removed it.)

Ideally you would not run the dependent ASID authorized at all. There are at least two ways you could do that, I believe:
(1) z/OS provides services via WLM that (if I remember correctly) allow an authorized server to route requests to an unauthorized servant, with z/OS managing the identity that is used for each request.

(2) Using UNIX functions you could fork() a new address space to handle the request, switch the identity while still running authorized, and then execmvs() a new unauthorized program to run the request, return the results, and terminate. This does have the dependent ASID running authorized briefly, but the execmvs() takes care of cleaning things up so unauthorized code can then run safely.

In any case, if you have not been running REXX execs and TSO or ISPF functions before in your dependent address spaces, you will probably have some major redesign to do in order to run them safely. And if you're going to do some major redesign you should start afresh with something that is architecturally safer, such as (1) or (2) above.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-19 13:05:01 UTC
Reply
Permalink
Raw Message
(2) is interesting. Actually my first thought was to use ASCRE to spawn a new ASID to execute the command but
I have heard that address space creation/destruction is a major overhead and so focused on ATTACH.

Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Walt Farrell
Sent: 19 May 2017 19:34
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
Post by Robin Atwood
The situation would be that the client routes a command to the server
on the host which routes it to a dependent ASID. The DA gets the ACEE
of the user and executes the command via IJKEFTSR. The command is one of a suite of Rexx execs in a library allocated to the DA which executes ISPF services (eg, to copy some members). Without wilful collaboration of a sysprog I am struggling to see how this could be subverted by a malicious user. However, if you can see something >please let me know!
It all comes down to the fine (and unknown to us) details of how your dependent ASID initializes, what storage key the initiator ATTACHes it in, what storage keys it uses, and how you plan to remove authorization (JSCBAUTH) before invoking IKJEFTSR. (And that you never restore authorization (JSCBAUTH) once you've removed it.)

Ideally you would not run the dependent ASID authorized at all. There are at least two ways you could do that, I believe:
(1) z/OS provides services via WLM that (if I remember correctly) allow an authorized server to route requests to an unauthorized servant, with z/OS managing the identity that is used for each request.

(2) Using UNIX functions you could fork() a new address space to handle the request, switch the identity while still running authorized, and then execmvs() a new unauthorized program to run the request, return the results, and terminate. This does have the dependent ASID running authorized briefly, but the execmvs() takes care of cleaning things up so unauthorized code can then run safely.

In any case, if you have not been running REXX execs and TSO or ISPF functions before in your dependent address spaces, you will probably have some major redesign to do in order to run them safely. And if you're going to do some major redesign you should start afresh with something that is architecturally safer, such as (1) or (2) above.

--
Walt

----------------------------------------------------------------------
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
Walt Farrell
2017-05-19 13:36:02 UTC
Reply
Permalink
Raw Message
Post by Robin Atwood
(2) is interesting. Actually my first thought was to use ASCRE to spawn a new ASID to execute the command but
I have heard that address space creation/destruction is a major overhead and so focused on ATTACH.
My first question would be whether you're processing enough requests, frequently enough, to worry about the overhead. If you're not used that frequently, maybe the overhead won't matter?

But if it does matter, UNIX processes tend to run in different address spaces, and the system has optimization for that. Using UNIX functions like fork()/execmvs() rather than ASCRE should eliminate a lot of the overhead you're concerned about.

Using the WLM functions that z/OS provides for situations such as yours might do even better. I'm not sure about that.

Either should (more) easily avoid the integrity pitfalls you're headed toward.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-05-19 15:42:27 UTC
Reply
Permalink
Raw Message
Post by Walt Farrell
Post by Robin Atwood
(2) is interesting. Actually my first thought was to use ASCRE to spawn a new ASID to execute the command but
I have heard that address space creation/destruction is a major overhead and so focused on ATTACH.
My first question would be whether you're processing enough requests, frequently enough, to worry about the overhead. If you're not used that frequently, maybe the overhead won't matter?
And, an address space created by fork()/BPXAS lingers after the process terminates
(I've observed in system log for 30 minutes) so another fork() within that interval
needn't start a new address space.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-22 07:12:59 UTC
Reply
Permalink
Raw Message
Thanks. Potentially there will be a lot of transactions so I will look into this, although starting the TMP after a fork() seems a bit fraught!

--
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: 19 May 2017 22:43
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
Post by Walt Farrell
Post by Robin Atwood
(2) is interesting. Actually my first thought was to use ASCRE to
spawn a new ASID to execute the command but I have heard that address space creation/destruction is a major overhead and so focused on ATTACH.
My first question would be whether you're processing enough requests, frequently enough, to worry about the overhead. If you're not used that frequently, maybe the overhead won't matter?
And, an address space created by fork()/BPXAS lingers after the process terminates (I've observed in system log for 30 minutes) so another fork() within that interval needn't start a new address space.

-- 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
Peter Relson
2017-05-22 17:23:07 UTC
Reply
Permalink
Raw Message
As best I can tell (unless I missed it), the OP has not answered the
question of whether they understand that after doing something to remove
authorization from the space, they are OK with leaving the space
unauthorized. If that is not the case, we might as well end the
discussion because there is no way to do that while maintaining system
integrity, and it is unlikely anyone would accept such a "solution".

Walt Farrell has pointed out approaches that are conceivably OK.

ATTACH with RSAPF=YES should be off the table.

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
Loading...