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.