So, my situation is normal as far as the iSeries FTP server is concerned?
And that's because the FTP server has already decided it cannot fulfill the
GET request (because of the non-existent file) and thus is not calling the
FTP exit program (which would only be logging the request, in this case)?
Tom
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, October 22, 2012 2:09 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: FTP logging issue
On 22 Oct 2012 11:48, Tom Hightower wrote:
<<SNIP>> Logins are handled just fine, library/folder restrictions are
being handled no problem, SYS restrictions work. GETs are working and
are recorded, PUTs are working and are recorded. But the GET/PUT
failures aren't being logged; the 'FTP EXIT Program running'
entry isn't even being recorded (indicating that the exit program
isn't even being called - right?). I've got to be missing something,
but I don't know what. <<SNIP>>
IIRC the described behavior is normal. I recall my exit-program was not
called for any requests that had already been rejected by the FTP
server\client; i.e. my program was not allowed to feedback any reject\allow
for the operation, because the FTP had already made the decision to reject.
However my usage-of\coding-to that feature was very long ago on a
now-ancient release. Assuming that recollection validly reflects the
current behavior, I offer FWiW...
Thus I infer what has been missed is, at least partly, the intentions of
the providers of the FTP server\client request validation exit-point.
Just a guess... that they chose not to send requests to the exit program
whenever the request could not be fulfilled anyway; be it per syntax errors
or existence. Also entirely possible, that some design\implementation
details limited the ability of the exit to operate differently [at least
easily effected] than it does. Consider for example if the exit program
would run for such a request: that opens new concerns for requirements of
the FTP to re-validate the request for the possibility that the exit program
or other concurrent activity could have /resolved/ the condition, and if the
exit-program gives feedback that allows the failed\implicitly-rejected
operation, then should FTP re-evaluate its prior decision to reject the
operation or reject the operation without regard to exit-program feedback?
IMO however, a syntactically correct request should be logged [thus the
exit program called] in order that an exit-program could learn the names of
what a user had intended\attempted to access, irrespective of either the
existence of the object or the authority of the user to the specified object
name. For example, if a user issues "MGET /qsys.lib/password.file/*.mbr",
then I would want my logging program to learn of that reference, even if I
know no such file exists or that the user is not authorized [and thus will
be prevented from getting any data anyway]. Obviously I can see there would
be difficulty for the exit-point to pass on gibberish requests to the
exit-program, but for any request that passes syntax checking and will fail
presumably only due to non-existence [or lack of authority], there seems to
be a legitimate reason for the exit-point to invoke the exit-program to
inform of that request, even though the FTP has already decided the request
can not go forward.
The documentation notes that "[t]he request validation exit points can be
used to restrict operations which can be performed by FTP users", and the
chosen wording "can be performed" vs "may be performed" could be important.
The documentation suggests that "[t]he FTP Request Validation exit program
gives you control over whether to accept or reject an operation", so there
arguably may be little reason for the exit-point to call the exit-program
when the operation will be rejected irrespective of what the exit program
might decide to feedback.? That is, why should the exit-program be able to
decide whether to allow a request that can not be fulfilled by FTP, because
the FTP has already decided the request must be rejected? The exit-point
owners [the OS FTP server\client] may legitimately feel there is no need to
call the exit-program in such cases. Indeed, they describe additionally
that the "[d]ecisions made by exit programs are *in addition to* any
validation that is performed by the FTP client or FTP server application."
[emphasis mine]
So it seems they probably consider their existence check a legitimate
validation by the FTP which precludes any additional validation by the
exit-program. If so, I think a request for a design change would be the
only recourse for the possibility of having the exit point start calling for
[some set of; probably non-gibberish] requests that currently will never
effect that call.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
