Jim There are too many points of contact between what you describe and what APAR "PQ92115: RSH CLIENT FAILS WHEN RESTRICTLOWPORTS IS CODED IN TCPCONFIG" describes for it to be dismissed as "similar but not exactly the same problem". I'm almost certain it *is* the same problem but there is a mystery over the AC value.
The authors of the APAR text state that going from V1R4 to V1R5 the linkage edit of the RSH client module changed from AC(1) to AC(0) but you are reporting that in V1R11, it is back to AC(1) - undergarments are not smooth! - AC(1) is a necessary but not a sufficient condition to be APF-authorised. APF- authorisation requires the first program module loaded be loaded from an authorised partitioned data set in addition to being linkage edited with AC=1. Note also that the logic which allows access to a port number and protocol, TCP or UDP, combination is as follows: - If the program is APF-authorized, allow - If the program is running with UID(0), allow - If there is a PORT statement list entry for this address space name - and if any SAF specification is met - for the port number and protocol combination, allow - If there is some restriction explicitly specified through a PORT or PORTRANGE statement, do not allow[1] - If RESTRICTLOWPORTS applies to port range 1-1023 and the relevant protocol, TCP or UDP, do not allow - Otherwise allow Before I decided the above logic might be useful to include, I'd composed the following: > I'd rather not specify UNRESTRICTLOWRPORTS but that seems to be the only resolution. As a matter of interest, there is no inherent problem with UNRESTRICTLOWPORTS. The original idea behind specifying a PORT number as an entry in a PORT statement list was to ensure that only a particular address space "name" could run the program which specified a particular port number and protocol, TCP or UDP, combination in the structure referenced in a bind() call. Without such an entry in the PORT statement, any old tom, dick or harry address space name could run a program which referenced the port number and protocol combination. RESTRICTLOWPORTS is - from my perspective! - a relatively recent "enhancement" which allows all port numbers in the range 1-1023, for TCP, if specified on the TCPCONFIG statement, or UDP, if specified on the UDPCONFIG statement, to be "reserved" and to be inaccessible if there is not a corresponding PORT statement list entry for the port number and protocol combination. - There is actually another mystery which is why a *client* in a TCP-based client-server relationship should use anything other than an "ephemeral port". An "ephemeral port" is selected from a range of numbers which just doesn't overlap with the range of port numbers restricted by the RESTRICTLOWPORTS parameter of the TCPCONFIG statement, namely 1-1023. I did check all of the z/OS Communications Server (CS) IP Configuration Guide manual, the z/OS CS IP Configuration Reference manual and the z/OS CS IP Users Guide and Commands manual but found nothing. However, it may be that what is unusual here is that you are using the IP component of z/OS CS as a client. Although this is however *not* a topic with which I have any experience, I believe that "ephemeral ports" are not as straightforward in a z/OS CS IP CINET environment as with, say, Windows! Strangely enough the z/OS UNIX System Services Planning manual does not use the word "ephemeral" for the port number assigned when a bind() call structure specifies 0 in the port number field. It uses the very peculiar term - not really all that correct! - "port 0, INADDR_ANY binds". I had to go to a redbook "IBM z/OS V1R12 Communications Server TCP/IP Implementation Volume 1: Base Functions, Connectivity, and Routing", SG24-7896-00, to be quite sure that "ephemeral ports" in a z/OS CINET context and INADDRANYPORT/INADDRANYCOUNT were the same - and even that wasn't quite a straightforward as the manual authors could have made it! Is it possible that you - and the customers who caused APAR PQ92115 to appear - have managed to specify a range for INADDRANYPORT/INADDRANYCOUNT which overlaps with 1-1023 and, consequently, you are trying to use the "low ports", the so-called "well-known ports", as "ephemeral ports"? - Finally, the ideal place to have aired this problem is in the IBMTCP-L list: For IBMTCP-L subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBMTCP-L - Chris Mason [1] I note there have been some changes in this area recently which look like they might be a bit complicated. However, you'd need to have specified something in order to be placing additional restrictions. On Wed, 2 Mar 2011 16:58:22 +0000, Jim McAlpine <[email protected]> wrote: >I'm running the RSH client on z/OS 1.11 and getting the following - > >EZA5051E The call to rcmd_af procedure failed: > EDC5112I Resource temporarily unavailable. rsn = 744C7246 >EZA4994I Foreign host aborted the connection. >I found the following apar for z/OS 1.5 - > >http://www-01.ibm.com/support/docview.wss?uid=isg1PQ92115 > >which describes a similar but not exactly the same problem. The >circumvention which is to specify UNRESTRICTLOWRPORTS also works with my >problem. However, whereas the problem in the above apar was caused by RSH >being linked AC(0), on z/OS 1.11 it is linked AC(1). I'd rather not >specify UNRESTRICTLOWRPORTS but that seems to be the only resolution. I've >also tried to give the user read access to BPX.SUPERUSER but that does not >work either. I can't find any other apars in this area. > >Any ideas. > >Jim McAlpine ---------------------------------------------------------------------- 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
