[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exit points and next version
Very impressive list Dennis, way to go.
Charles
On Sun, Oct 31, 2010 at 11:46 AM, Dennis Lovelady <iseries@xxxxxxxxxxxx> wrote:
> 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
> -----------------------------------------------------------------------
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------