[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Exit points and next version
Hi, everyone.
So the challenge of adding exit program checking to FTPAPI, and of breaking
the FTP API into smaller modules has borne fruit, and the new product is in
testing phase. It'll be a couple of weeks before the code is released, but
I wanted to put out this request for comments so that if anything important
has been overlooked, it can be addressed.
At present, here are the key changes. I would greatly appreciate any
comments / questions that come from this.
Also, I'd like to understand the approach/methodology used for submitting
new versions...
---
The API is now broken into these modules:
Externally-exposed routines (such as FTP_Open, FTP_Put, ...) are in
FTPAPIEXT
Session management getters and setters are in FTPAPISSN
Internal workings (such as tcp_conn, data reformatters, translations,
...) are in FTPAPIINT
Exit Program checking is in FTPAPIXTP
All of these modules share a single FTPAPIINTH header (copybook)
---
Where reasonable to do so, message constants have been removed, replaced by
message IDs (and FTPAPIMSG message file has been added to the project). The
60-byte message retrieval mechanism remains in place, with a new optional
parameter (default *Off) that allows longer text to be returned (varying
length, up to 512 bytes.
---
For backward compatibility, socket handle continues to be used for session
selection by the externally-exposed routines. However, where reasonable to
do so, "sessions" are internally managed through Session Index (named
ssnIdx), and there is greater separation between the use of "socket" and
"session" within the code.
---
The use of MODS is removed, replaced by qualified, based data structures and
on-the-fly memory de/allocation. (Session management using MODS among more
than one module proved to be far too cumbersome and error prone.) This
raises the OS requirement to (at least) V5R1. The session attributes are
wholly contained within the FTPAPISSN module, and are accessible only
through setters and getters.
Emulation of the IBM-supplied FTP Client's usage of Exit points is
controlled by calling setSysExitPtUsage(*On | *Off). If this procedure is
not called, this emulation does not occur. Since IBM's implementation
supports the rejection of activity at the session level, functions
setGlobalAbort() and getGlobalAbort() have been introduced to provide
similar control. Present code includes code like this every time
initFtpApi() is referenced:
initFtpApi() ;
if getGlobalAbort() ;
return -1 ;
endif ;
...
Also, key points in the code attempt to ensure that nothing "useful" is done
if Global Abort has been set. To that end, the following procedures contain
the same "if getGlobalAlert()" block at their tops: opnFile() recvLine()
sendLine() sendLine2() resolveIP() tpc_conn()
I can envision other circumstances that would cause us to want to
setGlobalAbort() but no others besides rejection of session initialization
have been implemented at this time.
---
Several of the procedures have been changed from CONST CHAR parameters to
pointers with attributes VALUE OPTIONS(*STRING). This eliminates the
differences between certain functions (like FTP_Conn and FTP_ConnLong).
---
Large sections of code have been converted to free-form. I expect the
remaining to be free-form before final release, in about two to three weeks
or so.
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"A fashion ten years before its time is indecent. Ten years after its time
it is hideous. After a century, it becomes romantic."
-- James Laver
> Someone at IBM wrote an example retrieve and call exit program. So the
> first step would be fairly simple
>
> http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic
> =/apiref/ileRetrieveILERPG.htm
>
> Add this code into the ftp procedures. Ignore all results! And presto,
> all is good. :)
>
> It appears that initFtpAPi is called from all exported procedures. With
> a little bit of work to pass the appropriate functions, it might be
> possible to add the check there. Since initFtpApi doesn't return any
> parameters, error code would need to be added. Hmmmm, starting to get
> to be a bit of fun!
>
> Good luck if take this on.
>
>
> > -----Original Message-----
> > From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-
> > bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dennis Lovelady
> > Sent: Thursday, September 30, 2010 4:07 AM
> > To: 'HTTPAPI and FTPAPI Projects'
> > Subject: RE: Exit points
> >
> > Scott, thanks for your reply, and I quite agree with you! This is
> road
> > well
> > traveled between me and the other team involved. This is the same
> > group
> > that has completely disabled all CPYSRCF capability via public
> > authority for
> > God knows what reason, blind to the fact that CPYF can accomplish the
> > same
> > end. I cannot use option 3 on a PDM screen to copy a source member,
> > but I
> > can create a new source member and then copy the original into that.
> > This
> > is just one clear example of the knowledge base and need for control
> > from
> > that group.
> >
> > They want their bankey. If it makes them comfortable and makes them
> > feel
> > like they're in control, then so be it. You are welcome to take that
> > battle
> > up with that team - I'll provide phone numbers.
> >
> > My goal was not to seek permission, it was to find out how to provide
> > that
> > bankey. I will have a look at the easy400 suggestion later today.
> >
> > Dennis Lovelady
> > http://www.linkedin.com/in/dennislovelady
> > --
> > "United Nations: Where America feeds the hands that bite it."
> > -- Gregory Nunn
> >
> > > Quite honestly, I don't see "securing" a client program to be a
> means
> > > of
> > > providing security. That goes double for one that's open source,
> > where
> > > the user can go in and change the way it calls the exit point!
> > >
> > > 1) What's to stop the user from downloading/installing another FTP
> > > client program? (None of the ones in PASE understand exit points!)
> > >
> > > 2) On your Windows or Linux box (where FTP software is easy to come
> > by)
> > > would you rely on an exit point if such a thing existed? When the
> > > user
> > > can easily download and install another program? Wouldn't you
> think
> > > the
> > > whole idea of an exit point is kinda silly?
> > >
> > > 3) Unlike the IBM client, FTPAPI is designed for use only from a
> > > computer program. i.e., a user will never use it directly, and
> it's
> > > operation will always be automated by a programmer's RPG program.
> > > Given
> > > that, isn't the security supposed to be provided by the program
> that
> > > calls FTPAPI? Rather than FTPAPI itself?
> > >
> > > 4) If you add exit point support to FTPAPI, what's to stop a
> > programmer
> > > from writing their own FTP client and bypassing the exit points
> that
> > > way?
> > >
> > > I guess, to me, there's a pretty big difference between a tool
> > designed
> > > for the user to use, and a tool designed only as an API to be
> called
> > > from programs.
> > >
> > > Having said all of that... if you really want to integrate it with
> > the
> > > IBM exit point system, feel free to write the code and contribute
> it
> > > back to the project.
> > >
> > >
> > > On 9/29/2010 6:56 PM, Dennis Lovelady wrote:
> > > >
> > > > Hi, folks, this is my first post here.
> > > >
> > > >
> > > > As a preface, I have searched the archives for "exit program" and
> > for
> > > QIBM_QTMF
> > > > _CLIENT_REQ and for PowerLock with not much result.
> > > >
> > > > There was a question from someone in 2004 asking why settings in
> > > PowerLock have
> > > > no apparent effect on FTPAPI. Apparently the poster didn't
> know
> > > how PowerLock
> > > > works (or how it doesn't, in this case). Answer: PowerLock
> > control
> > > is install
> > > > ed at the QIBM_QTMF_CLIENT_REQ exit point.
> > > >
> > > > Until I started working with FTPAPI very recently, I had assumed
> > that
> > > IBM someh
> > > > ow tied that exit point to the FTP ports. (Naive, now I think
> about
> > > it.) Appar
> > > > ently instead, the FTP client program itself makes the necessary
> > > hooks.
> > > >
> > > > I mentioned on another list that our auditors wouldn't allow this
> > > program on on
> > > > e of the main systems I work with since it seems to lack the kind
> > of
> > > control th
> > > > at they want (for example, some users can GET, some can PUT or
> GET,
> > > and some ca
> > > > n only do DIR operations). (This is all managed by PowerLock
> > > controls at this
> > > > point.)
> > > >
> > > > So my question is, Have any on this list made an attempt to fit
> the
> > > IBM exit po
> > > > ints with FTPAPI? (I have no clue how that would be done, nor if
> it
> > > even *can*
> > > > be done in a supported manner.) I'd love to use this decidedly
> > > better solution
> > > > but am stymied except on my development machines.
> > > >
> > > > I appreciate your responses.
> > > >
> > > >
> > > > Dennis E. Lovelady
> > > > AIM/Skype: delovelady MSN: fastcounter@xxxxxxxxxxxx
> > > > [1]www.linkedin.com/in/dennislovelady --
> > > > "Since I moved to suburbia I found out the purpose of those
> > > railroad
> > > > timetables. Without them there would be no way of knowing
> how
> > > late
> > > > your train is."
> > > > -- Gregory Nunn
> > > >
> > > > References
> > > >
> > > > 1. http://www.linkedin.com/in/dennislovelady
> > > >
> > > >
> > > >
> > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > This is the FTPAPI mailing list. To unsubscribe, please go to:
> > > > http://www.scottklement.com/mailman/listinfo/ftpapi
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > This is the FTPAPI mailing list. To unsubscribe, please go to:
> > > http://www.scottklement.com/mailman/listinfo/ftpapi
> > > -------------------------------------------------------------------
> --
> > --
> >
> > ---------------------------------------------------------------------
> --
> > This is the FTPAPI mailing list. To unsubscribe, please go to:
> > http://www.scottklement.com/mailman/listinfo/ftpapi
> > ---------------------------------------------------------------------
> --
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------