On Thu, 25 May 2017 19:33:22 -0500, John McKown
wrote:
>Thanks. I may put in an RFC on the BPX1FRK documentation to ask that it
>explicitly state that the APF status is maintained. Granted, in the Usage
>Notes, there is the sentence: "In other respects, for z/OS UNIX the child
>is identical t
On Thu, May 25, 2017 at 4:52 PM, Walt Farrell
wrote:
> On Thu, 25 May 2017 14:24:05 -0500, John McKown <
> john.archie.mck...@gmail.com> wrote:
>
> >Well, from what I vaguely gather, this entire thread started off with the
> >question of "how does an APF authorized program run a non-APF authoriz
On Thu, 25 May 2017 14:24:05 -0500, John McKown
wrote:
>Well, from what I vaguely gather, this entire thread started off with the
>question of "how does an APF authorized program run a non-APF authorized
>program from a library not on the APF list?". Apparently the OP was trying
>this and got a
On Thu, May 25, 2017 at 1:50 PM, Walt Farrell
wrote:
> On Thu, 25 May 2017 11:46:20 -0500, John McKown <
> john.archie.mck...@gmail.com> wrote:
>
> >On Thu, May 25, 2017 at 10:44 AM, Walt Farrell
> >wrote:
> >> execmvs() would be better than LINKX or ATTACHX for this scenario, in
> >> general, a
On Thu, 25 May 2017 11:46:20 -0500, John McKown
wrote:
>On Thu, May 25, 2017 at 10:44 AM, Walt Farrell
>wrote:
>> execmvs() would be better than LINKX or ATTACHX for this scenario, in
>> general, as it handles all the environmental cleanup and handles any
>> necessary authorization issues.
>>
>
On Thu, May 25, 2017 at 10:44 AM, Walt Farrell
wrote:
>
>
> >a UNIX directory. So I was not envisioning him using a UNIX exec()
> function
> >to run the non-APF program in the child. I was thinking the "historic" use
> >of LINKX or maybe ATTACHX. The mention of a TASKLIB for a dynamically
> >a
On Thu, 25 May 2017 08:11:31 -0500, John McKown
wrote:
>On Wed, May 24, 2017 at 2:28 PM, Peter Hunkeler wrote:
>
>> > The above is why I really "push" the UNIX fork() alternative.
>> [snip]
>>
>> >If a "steplib" is needed, the initial child program can simply DYNALLOC
>> the DSNs and then use a
>perhaps attaching as a job step may be an answer?
No it is not.
The fact that the initiator uses RSAPF=YES simply correlates to the fact
that that option is intended for the initiator's use.
Peter Relson
z/OS Core Technology Design
---
On Wed, May 24, 2017 at 2:28 PM, Peter Hunkeler wrote:
> > The above is why I really "push" the UNIX fork() alternative.
> [snip]
>
> >If a "steplib" is needed, the initial child program can simply DYNALLOC
> the DSNs and then use an ATTACHX with a TASKLIB.
>
> Assuming there will be an exec() in
As the documentation clearly states:
"The system checks for this attribute only when the program is being
invoked
with a parameter string of more than 100 bytes and the program is
APF authorized. In this case, if the LONGPARM attribute is not set on,
the system fails the invocation. "
Wha
On Wed, 24 May 2017 16:40:16 -0400, Jim Mulder wrote:
>
> Uhhh, Clem's program is not the Initiator, and does not
>do what the Initiator does to request LongParm checking, so no
>LongParm checking is done for its ATTACHes.
>
Sounds like a bug. Or an integrity threat. If I had Clem's program
I
> > That is not the way the Initiator works. The Initiator is not
> >APF-authorized.
> >
> I'll assume Initiator uses an SVC or PC to launch the program with
> suitable APF-authority (in a separate address space?) similar to what
> fork() and BPX1EXM do. What component performs the allocations
On Wed, 24 May 2017 21:28:26 +0200, Peter Hunkeler wrote:
>> The above is why I really "push" the UNIX fork() alternative.
>[snip]
>
>>If a "steplib" is needed, the initial child program can simply DYNALLOC the
>>DSNs and then use an ATTACHX with a TASKLIB.
>
>Assuming there will be an exec() in
> The above is why I really "push" the UNIX fork() alternative.
[snip]
>If a "steplib" is needed, the initial child program can simply DYNALLOC the
>DSNs and then use an ATTACHX with a TASKLIB.
Assuming there will be an exec() in the forked process, a steplib can be setup
simply by setting
On Wed, 24 May 2017 13:22:23 -0400, Jim Mulder wrote:
> That is not the way the Initiator works. The Initiator is not
>APF-authorized.
>
I'll assume Initiator uses an SVC or PC to launch the program with
suitable APF-authority (in a separate address space?) similar to what
fork() and BPX1EXM d
t; BRR14 AND BACK WE GO
> *
> --
>
>
> Clem Clarke
>
>
> Robin Atwood wrote:
>
>> Yes, the point was taken. I am now investigating using fork() to spin-off
>> another address space.
>>
>> Thanks
>> Robin
>>
&
All I can tell you is this. There are hard drives being brought into my
home with CD blanks and being taken out one at a time and sold.
Various devices being connected to the router and live streamed.
When Bright House came to install the new router I ordered I was told it
was set up and secure.
On Wed, May 24, 2017 at 12:22 PM, Jim Mulder wrote:
> That is not the way the Initiator works. The Initiator is not
> APF-authorized.
>
> Does your program use any key 8 storage (like the save area that was
> provided when your program was ATTACHed, or the subpool 0 area that you
> FREEMAIN
That is not the way the Initiator works. The Initiator is not
APF-authorized.
Does your program use any key 8 storage (like the save area that was
provided when your program was ATTACHed, or the subpool 0 area that you
FREEMAIN when the program that you ATTACHed ends)?
Could the unauthor
Clarke
Robin Atwood wrote:
Yes, the point was taken. I am now investigating using fork() to spin-off
another address space.
Thanks
Robin
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: 23 May 2017 00:24
To: IBM-MAIN@LISTS
EDU
Subject: Re: ATTACH with RSAPF=YES
On Tue, May 23, 2017 at 2:43 AM, Robin Atwood wrote:
> Yes, the point was taken. I am now investigating using fork() to
> spin-off another address space.
>
From my vague monitoring of this thread, I think that is a wonderful idea.
I don't know how
On Tue, May 23, 2017 at 2:43 AM, Robin Atwood wrote:
> Yes, the point was taken. I am now investigating using fork() to spin-off
> another address space.
>
From my vague monitoring of this thread, I think that is a wonderful idea.
I don't know how much you're "in to" what can be done, but there
: Re: ATTACH with RSAPF=YES
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
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 Technol
2017 22:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
On Fri, 19 May 2017 08:37:00 -0500, Walt Farrell wrote:
>On Fri, 19 May 2017 20:05:43 +0700, Robin Atwood wrote:
>
>>(2) is interesting. Actually my first thought was to use ASCRE to
>>spawn a new ASID to e
On Fri, 19 May 2017 08:37:00 -0500, Walt Farrell wrote:
>On Fri, 19 May 2017 20:05:43 +0700, Robin Atwood wrote:
>
>>(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 ov
On Fri, 19 May 2017 20:05:43 +0700, Robin Atwood wrote:
>(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 b
@LISTSERV.UA.EDU] On Behalf
Of Walt Farrell
Sent: 19 May 2017 19:34
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
On Fri, 19 May 2017 14:32:27 +0700, Robin Atwood wrote:
>The situation would be that the client routes a command to the server
>on the host which routes i
On Fri, 19 May 2017 14:32:27 +0700, Robin Atwood wrote:
>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
@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: 19 May 2017 01:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
On Thu, 18 May 2017 08:09:03 -0700, Charles Mills wrote:
>I hope you are getting the idea how risky this entire approach is. You
>are playing "you bet you
Harminc
Sent: 18 May 2017 23:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
On 18 May 2017 at 08:56, Robin Atwood wrote:
> 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 auth
On Thu, 18 May 2017 08:09:03 -0700, Charles Mills wrote:
>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
On 18 May 2017 at 08:56, Robin Atwood wrote:
> 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 un
ERV.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
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Thursday, May 18, 2017 8:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: ATTACH with RSAPF=YES
Tom answered most of your question but in addition
> Can it get authorised?
I don't
--Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Robin Atwood
Sent: Thursday, May 18, 2017 5:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
What is the situation of a module that is loaded from an authorised librar
On Thu, 18 May 2017 19:56:27 +0700, Robin Atwood wrote:
>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 aut
20:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which runs APF authorised.
You need to reject that requirement. It cannot be accomplished while
maintaining system
IN@LISTSERV.UA.EDU
:>Subject: Re: ATTACH with RSAPF=YES
:>
:>On Tue, 16 May 2017 20:42:42 +0700, Robin Atwood 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 prope
Peter-
Thanks for this, I shall ponder.
Robin
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: 16 May 2017 20:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
We have a requirement to attach user
@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
On Tue, 16 May 2017 20:42:42 +0700, Robin Atwood 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
>>
On Tue, 16 May 2017 20:42:42 +0700, Robin Atwood 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
>>
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which runs APF authorised.
You need to reject that requirement. It cannot be accomplished while
maintaining system integrity. Use of something like "fork" can perhaps
accomplish the goal with
>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
---
On Tue, 16 May 2017 14:09:49 +0700, Robin Atwood wrote:
>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 I
AM
To: IBM-MAIN@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
Of Binyamin Dissen
Sent: 15 May 2017 20:56
To: IBM-MAIN@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
On 5/15/2017 12:45 PM, Greg Dyck wrote:
On 5/15/2017 11:27 AM, Paul Gilmartin wrote:
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
reque
On 5/15/2017 11:27 AM, Paul Gilmartin wrote:
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
On Mon, 15 May 2017 10:28:37 -0400, Steve Smith wrote:
>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 ini
Sent: Monday, May 15, 2017 7:29 AM
To: IBM-MAIN@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 ne
May 2017 15:18:38 +0700, Robin Atwood
> 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 ...
On Mon, 15 May 2017 15:18:38 +0700, Robin Atwood 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 ...
It _can_ do what you w
case?
On Mon, 15 May 2017 15:18:38 +0700 Robin Atwood 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 tr
On Mon, May 15, 2017 at 7:30 AM, Greg Dyck wrote:
> 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, becaus
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 sys
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
unautho
57 matches
Mail list logo
