PM17665: CHANGE AUTHORIZATION CHECKS AT SERVER FOR DB2/Z WHEN PRIVATE PROTOCOL IS DISABLED

Obtain the fix for this APAR.

APAR status

• Closed as new function.

Error description

• DB2DDF
  Changes to authorization checking at a DB2/z server when
  Private Protocol is disabled.
  ***************************************
  Additional symptoms and keywords: sqlcode551
   DSN6FAC PRIVATE_PROTOCOL NO
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All Distributed Data Facility (DDF) users.   *
  *                 Specifically where DB2 z/OS is accessed as   *
  *                 a server, via DRDA protocols, from remote    *
  *                 DB2 for z/OS client applications.            *
  ****************************************************************
  * PROBLEM DESCRIPTION: With the elimination of DB2 Private     *
  *                      Protocol in DB2 10 for z/OS, the        *
  *                      current DB2 server authorization        *
  *                      behavior relative to DB2 for z/OS       *
  *                      clients is no longer applicable.        *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  When a DB2 for z/OS server is accessed via DRDA protocols, the
  authorization behavior relative to remote DB2 for z/OS client
  applications is different than the authorization behavior
  relative to remote non DB2 for z/OS client applications.
  The authorization behavior for a DB2 for z/OS DRDA client
  application was treated differently because it was associated
  to a DB2 for z/OS Plan, and thus DB2 for z/OS server processing
  wanted to apply the same authorization behavior that users
  were accustom to with DB2 Private Protocol. That is, remote
  DB2 for z/OS DRDA, like Private Protocol, client application
  privileges are also inherited from the associated DB2 for z/OS
  Plan owner ID and this privilege inheritance has historically
  been honored by DB2 for z/OS servers relative to remote
  DB2 for z/OS client applications only.
  Now that DB2 Private Protocol is being eliminated, this
  DB2 for z/OS server privilege inheritance behavior (relative
  to remote DB2 for z/OS DRDA client applications) is no
  longer applicable and is being eliminated for the benefit of
  consistent authorization behavior with respect to non
  DB2 for z/OS client applications.
   NOTE:
    This APAR changes DB2 for z/OS server authorization behavior
    with respect to remote DRDA client applications.
    . Non DB2 for z/OS clients are not affected by this change.
    . DB2 for z/OS DRDA clients that access a DB2 for z/OS V8
      or DB2 9 for z/OS server (with Private Protocol disabled),
      or a DB2 10 for z/OS server (where Private Protocol has
      been eliminated), MAY be affected by this change.
  

Problem conclusion

• DB2 for z/OS server authorization processing, relative to
  remote (via DRDA) DB2 for z/OS client applications only, has
  been changed to behave consistently with the current behavior
  relative to remote non DB2 for z/OS clients. This new server
  authorization behavior essentially represents more stringent
  authorization requirements that must now be met.
  **ATTENTION**
  After applying this APAR/PTF, access from remote DB2 for z/OS
  client applications, via DRDA, MAY now fail with SQLCODE
  -551. This will likely occur during the process of converting
  remote DB2 for z/OS applications from Private Protocol to DRDA
  protocol, but it may also occur if existing DRDA related
  application environments relied on the authorization behavior
  that has been eliminated. Authorization adjustments must be
  made to satisfy the condition described by the -551 SQLCODE.
  It is extremely difficult to predict in advance any potential
  remote DB2 z/OS applications that may be affected by this
  change in DB2 server authorization behavior. As a result,
  users must be aware of the potential that -551 SQLCODE
  conditions can result from this APAR/PTF and be prepared to
  make the necessary authorization adjustments.
  . DB2 for z/OS V8 and DB2 9 for z/OS users:
    If the DSN6FAC PRIVATE_PROTOCOL subsystem parameter (see
    APAR PK92339 for more information) is set to NO, to prevent
    Private Protocol usage, and DB2 for z/OS client applications
    unexpectedly receive SQLCODE -551 (after the APAR/PTF is
    applied), you also have the alternative to temporarily set
    the PRIVATE_PROTOCOL subsystem parameter to YES to restore
    authorization processing to the old behavior. This technique
    can be used to prevent further application outages while the
    authorization condition is being resolved. Once the problem
    is resolved, you can set the PRIVATE_PROTOCOL subsystem
    parameter back to NO.
  . DB2 10 for z/OS users:
    Other than potentially removing the APAR/PTF, if possible,
    there is no technique to restore old authorization
    behavior since DB2 10 for z/OS does not support Private
    Protocol. Users must make the necessary authorization
    adjustments to satisfy the condition described by the -551
    SQLCODE.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UK65969 UK65970 UK65971

Modules/Macros

• DSNLTACC DSNLXRCS
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• RA10 PSY UK65969

     UP11/04/05 P F104

• R810 PSY UK65970

     UP11/04/05 P F104

• R910 PSY UK65971

     UP11/04/05 P F104

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.