Hi,
A lot of years ago (VSE age), I saw a similar problem: how to protect an
exec that puts controlled programs in production.
That time, my solution was a simple ASSEMBLER program (public) that links
another mdisk (SUPPORT 11F if I remember correctly), and calling the
correct EXEC who did all the checks and finish detaching the mdisk.
The only problem was to recompile the program all the times when the mdisk
password was changed.
I will search for this program source into my backups... If found, I put
the program in this list...
______________________________________________
Clovis
From: Les Koehler <vmr...@tampabay.rr.com>
To: IBMVM@LISTSERV.UARK.EDU
Date: 15/10/2010 02:07
Subject: Re: REXX that verify what MINIDISK is a file
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
Sergio,
As Scott suggests, compiling is the first step to protect yourself from
getting
calls about tools that are not *your* tools.
The second step, assuming you can't get the tool installed in a shared
segment
(or whatever they call it these days), is to check that it is executing
from an
EXECLOAD from the correct disk. If not, then EXECLOAD it with the PUSH
option,
re-invoke it and then EXECDROP it.
Your tracking mechanism should use the same technique.
You might want to consider allowing a specified userid run it from disk for
testing purposes.
Another advantage to doing this is that you avoid the problem of users
running
back-level code that was copied to some other disk earlier in the search
order.
Back in the days when I worked at IGS in Tampa, this was one of the biggest
problems we constantly faced. Someone would create a 'collection' of tools
from
several disks in order to avoid using up all the mode letters. Then they'd
have
everyone else in their department link&access the 'department' disk. Of
course
they never checked to see if the *original* disk had been updated with a
later
version!
A good tracking facility helps in this area as well. You can just look at
the
tracking data and tell the complainer "You're not running the current
version of
MY tool!"
Just be real careful about what you protect this way. For instance, the
Rexx
compiler execs are 'sample' code and can be greatly enhanced by the user to
do
such things as add an automatic Copyright statement from a lookup file, as
well
as a 'footprint' that identifies the source code disk, date/time of the
source, etc.
Les
Scott Rohling wrote:
> Yes - exactly what I did to test my code snippet.
>
> You'll never be able to stop people from copying files to their A disk -
and
> making modifications - including removing any checks you make for an X
disk,
> etc. Users can do an EXECDROP or EXECLOAD on their own - there's not
many
> good ways to stop a determined user from shooting themselves in the foot
if
> they want to.
>
> Sergio - maybe the best answer to solve the root problem is to compile
the
> REXX code? People could still have old copies of CATAA .. but at least
if
> it's compiled, they can't make changes to the current code.
>
> Scott Rohling
>
> On Thu, Oct 14, 2010 at 3:45 PM, Michael Coffin
<michaelcof...@mccci.com>wrote:
>
>> Just checking the filemode of the program will not guarantee that that
it
>> is running from MAINT 31A. If I:
>>
>>
>>
>> ACCESS 191 X
>>
>>
>>
>> Then execute CATAA with Parse Source in it, the Parse Source will show
it
>> is running from the mdisk accessed as X – but it’s my 191, not the MAINT
>> 31A.
>>
>>
>>
>> Look into CP QUERY MDISK to verify that the disk accessed as X is MAINT
>> 31A.
>>
>>
>>
>> -Mike
>>
>>
>>
>> *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]
*On
>> Behalf Of *Sergio Lima
>> *Sent:* Thursday, October 14, 2010 5:17 PM
>>
>> *To:* IBMVM@LISTSERV.UARK.EDU
>> *Subject:* Re: REXX that verify what MINIDISK is a file
>>
>>
>>
>> Hello Mike,
>>
>> Thanks very much from your good explanation.
>>
>> We need that the user execute our EXEC from a public dasd (Maint 31a),
>> because, We try track who executed this, the date, the time, and another
>> thinks, like Filename, Filetype, Filemode.
>> This EXEC do a Compilation of programs here, and now, the people here,
want
>> have a little control about what was compiled, and others thinks.
>>
>> Thanks again, and Best Regards,
>>
>> Sergio
>>
>> ------------------------------
>>
>> Date: Thu, 14 Oct 2010 15:03:36 -0500
>> From: mike.wal...@hewitt.com
>> Subject: Re: REXX that verify what MINIDISK is a file
>> To: IBMVM@LISTSERV.UARK.EDU
>>
>>
>> It is pretty unusual to force an EXEC to execute from a specific disk.
>> About 98% of the time I do that is when running a common 'PROFCMS EXEC'
in
>> everybody's "PROFILE EXEC" - the "PROFCMS EXEC" complains when it is not
>> executing from the Y-disk (or the our HAINST alternative to IBM's
CMSINST
>> NSS). Also, a common "PROFILE XEDIT" complains of the same results
(after
>> it does some preliminary setup, it attempts to execute the user's
"userid
>> XEDIT" macro).
>>
>> But if you really need to execute an exec from a specific disk, from my
20
>> July 2009 post here:
>> Check out Kent Fiala's "DIREXEC" on the IBM VM Download page:
>> http://www.vm.ibm.com/download/packages/descript.cgi?DIREXEC
>>
>> That DIREXEC VMARC package should do exactly what you wish, and explains
>> that the included FMEXEC is syntactically easier to use for minidisk
>> files.
>>
>> But before you do that, please help us understand why you would want to
do
>> so. There may be much better solutions yo meet your need.
>>
>> Mike Walter
>> Aon Hewitt
>> The opinions expressed herein are mine alone, not my employer's.
>>
>> *"Sergio Lima" <sergiovm...@hotmail.com>*
>>
>> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
10/14/2010
>> 02:19 PM
>>
>> Please respond to
>> "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
>>
>>
>>
>> To
>>
>> IBMVM@LISTSERV.UARK.EDU
>>
>> cc
>>
>> Subject
>>
>> REXX that verify what MINIDISK is a file
>>
>>
>>
>>
>>
>>
>> Hello List,
>>
>> We are changing a REXX here for that this EXEC execute only if reside on
X
>> acessed minidisk.
>> So, try with STATE command without succesfull and now try with
LISTFILE
>> command.
>> If execute like this :
>>
>> 9 *-* 'LISTFILE cataa exec x (DATE STACK LIFO'
>> >>> "LISTFILE cataa exec x (DATE STACK LIFO"
>> 10 *-* if rc = 0
>> >>> "1"
>> *-* then
>> *-* do
>> 11 *-* pull x1 x2 x3 .
>> >>> "CATAA"
>> >>> "EXEC"
>> >>> "X2"
>> >.> "V 83 506 4 10/14/10 15:03:32"
>> 12 *-* say x1
>> >>> "CATAA"
>> CATAA
>> 13 *-* say x2
>> >>> "EXEC"
>> EXEC
>> 14 *-* say x3
>> >>> "X2"
>> X2
>> 15 *-* exit
>>
>> But, when try execute with filemode *, lookslike the program go to a
>> LOOPING :
>>
>> 9 *-* 'LISTFILE cataa exec * (DATE STACK LIFO'
>> >>> "LISTFILE cataa exec * (DATE STACK LIFO"
>> 10 *-* if rc = 0
>> >>> "1"
>> *-* then
>> *-* do
>> 11 *-* pull x1 x2 x3 .
>> >>> "CATAA"
>> >>> "EXEC"
>> >>> "X2"
>> >.> "V 83 506 4 10/14/10 15:03:32"
>> 12 *-* say x1
>> >>> "CATAA"
>> CATAA
>> 13 *-* say x2
>> >>> "EXEC"
>> EXEC
>> 14 *-* say x3
>> >>> "X2"
>> X2
>> 15 *-* exit
>> 9 *-* 'LISTFILE cataa exec * (DATE STACK LIFO'
>> >>> "LISTFILE cataa exec * (DATE STACK LIFO"
>> 10 *-* if rc = 0
>> >>> "1"
>> *-* then
>> *-* do
>> 11 *-* pull x1 x2 x3 .
>> >>> "CATAA"
>> >>> "EXEC"
>>
>> The command in the line show this :
>>
>> listfile cataa exec *
>> CATAA EXEC A2
>> CATAA EXEC X2
>> Ready; T=0.01/0.01 16:17:00
>>
>> Someone can help, how can verify if this EXEC is not running from X
disk ?
>>
>> Thanks very much,
>>
>> Sergio Lima Costa
>> Sao Paulo - Brazil
>> ------------------------------
>>
>>
>> The information contained in this e-mail and any accompanying documents
may
>> contain information that is confidential or otherwise protected from
>> disclosure. If you are not the intended recipient of this message, or if
>> this message has been addressed to you in error, please immediately
alert
>> the sender by reply e-mail and then delete this message, including any
>> attachments. Any dissemination, distribution or other use of the
contents of
>> this message by anyone other than the intended recipient is strictly
>> prohibited. All messages sent to and from this e-mail address may be
>> monitored as permitted by applicable law and regulations to ensure
>> compliance with our internal policies and to protect our business.
E-mails
>> are not secure and cannot be guaranteed to be error free as they can be
>> intercepted, amended, lost or destroyed, or contain viruses. You are
deemed
>> to have accepted these risks if you communicate with us by e-mail.
>>
>>
>>
>
