IMHO, a flaw in your thinking is your wanting to use someone else's ID
for some security related activity.   

Have the users stow their data in staging files. Upon some event (timer,
file creation, etc) a production job (the FTP) kicks off and does the
transfer under its own ID. There is a protected NETRC file that contains
the id/password for the remote site. If there is a need for the
originating user ID, then embed that in the data.  

This does not solve your problem, but it does reduce the scope to a
single ID/password to manage.  

This is an interesting case that demonstrates how encryption does not
add any security. All that would have need for the NETRC file would also
have to have the keys. The keys could then be easily compromised since
you cannot control what a user does with those keys. 

Only the Lone Ranger has silver bullets. And even those only worked for
a few years.  

HTH and good luck. 
 
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Charles Mills
Sent: Wednesday, January 04, 2006 4:43 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: FTP userid propagation

I just posted the NETRC question but perhaps I should instead ask the
fundamental underlying question. Here is what I want to do.
 
I want to have a program ABC running in a "normal" batch job that might
be
submitted by any of a large number of TSO users invoke FTP and have it
log
on to a remote z/OS FTP server and, among other things, submit a job. I
have
complete control over the INPUT (command) file which is built on the
fly.
Here is the key question: I would like the FTP logon to be with the
userid
of the original user who submitted the batch job. Do any of you creative
souls want to suggest a reasonable way to do this?
 

Charles Mills

 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to