IBM Support

Undesired PORTACCESS Violations

Troubleshooting


Problem

The SAF keyword is specified on one or more PORT or PORTRANGE reservation statements. They correctly allow the desired applications to use the requested ports and disallow unauthorized applications that explicitly request those ports. However, occasionally some unrelated application that attempts to use an ephemeral port receives a security violation for the SERVAUTH class EZB.PORTACCESS.sysname.tcpname.safname profile.

Symptom

If using RACF, the following message will be generated:

     ICH408I USER(uuuu) GROUP(gggg) NAME(nnnnnnnnnnnnnn)
     EZB.PORTACCESS.ssssssss.tttttttt.xxxxxxxx CL(SERVAUTH)
     INSUFFICIENT ACCESS AUTHORITY
     FROM EZB.PORTACCESS.*.*.xxxxxxxx (G)
     ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )

Cause

There are two possible causes:

  1. On systems configured for multiple TCPIP stacks (also called CINET), the INADDRANYPORT and INADDRANYCOUNT keywords are used by OMVS to select a port number to be used for ephemeral port requests. These keywords are specified in the BPXPRMxx PARMLIB member on the NETWORK statement. The default , if not specified, is 63000 and 1000, respectively. If some of the stack's PORT reservations in this range have SAF profiles specified, these requesters will be checked for authorization to the PORTACCESS profile.
  2. A PORT (or PORTRANGE) statement defining UDP port reservations with a wildcard ('*') jobname specification and a SAF keyword. In the search for an ephemeral port, the RACF access is still checked even though the port is eventually not chosen.

Resolving The Problem

Perform the following action(s) appropriate for which of the above listed causes is applicable to your system:

  1. Port reservations for the range identified by INADDRANYPORT and INADDRANYCOUNT should not have the SAF keyword. If an application must reserve one of these ports, either the application should be changed to move the port number used or the BPXPRMxx specification should be modified to use a different range of ports (all participating stacks may also need to be updated to reserve that range for OMVS).
  2. This problem has been corrected in the following releases:
    • z/OS 2.2 or above
    • z/OS 2.1 with PTF UI19430 (RSU1408) applied.
    • z/OS 1.13 with PTF UI18700 (RSU1408) applied.
    For earlier releases, or pending application of the appropriate PTF, the following action should be taken to avoid these SAF violations. Do not use a fully wildcarded jobname on a UDP port reservation with the SAF keyword. You may specify the jobname prefix (for example, ABC*) that will match all of the jobs intended to legitimately use this port. Code a separate PORT statement for each job name that can't match a pattern, or for multiple patterns.

    NOTE: This restriction does not apply to the use of an UNRSV specification (z/OS 1.10 or higher). Having a full wildcard for the job name on this specification will not cause spurious security violations for the referenced SAF profile.

[{"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Component":"All","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"1.6;1.7;1.8;1.9;1.10;1.11;1.12;1.13;2.1;2.2;2.3","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

Document Information

Modified date:
15 June 2018

UID

swg21237916

Page Feedback