IBM Support

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

A fix is available

Subscribe

You can track all active APARs for this component.

 

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 number

    PM17665

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    810

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2010-06-30

  • Closed date

    2011-03-18

  • Last modified date

    2011-06-15

  • 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.

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.1","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
15 June 2011