IBM Support

PM37300: CHANGE AUTHORIZATION CHECKS TO RECOGNIZE SECONDARY IDS 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 defect 149430 d149430 pm37300 dpm37300
    Change authorization check at server for DB2 for z/OS to
    recognize secondary IDs from DB2 for z/OS requesters when
    Private Protocol is disabled.
    additional search arguments: sqlcode551 execute
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All Distributed Data Facility (DDF) users.   *
    *                 Specifically where DB2 for 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 plan owner based     *
    *                      authorization behavior relative to      *
    *                      remote DB2 for z/OS client systems      *
    *                      is no longer applicable.                *
    *                      APAR PM17665 made changes to allow      *
    *                      users to move to this new               *
    *                      authorization environment however       *
    *                      additional new function is required.    *
    ****************************************************************
    * 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 accustomed 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.
    Changes were made via APAR PM17665 to help users move to the
    new authorization environment however additional changes are
    required.
    o Users need a more flexible environment.
      It may be difficult, and it may take time, for users to
      adjust their authorization rules to satisfy the new
      authorization environment. As a result, users require a
      mechanism to enable and disable this new authorization
      environment.
      In DB2 for z/OS V8 and V9, the DSN6FAC PRIVATE_PROTOCOL
      configuration parameter can be used for this. If the old
      authorization environment is required by remote DB2 for z/OS
      applications, the PRIVATE_PROTOCOL parameter may be set to
      YES, however this also allows actual usage, perhaps
      accidental, of Private Protocol. There is no solution for
      DB2 for z/OS V8 and V9 users who wish to prevent the usage
      of Private Protocol yet also retain the old authorization
      behavior that their remote DB2 for z/OS (DRDA) applications
      may still depend on.
      In DB2 10 for z/OS, there is no mechanism to enable or
      disable the new authorization environment. There is no
      solution for users to migrate to DB2 10 for z/OS that have
      remote DB2 z/OS (DRDA) client applications that may still
      depend on the old authorization behavior.
    o Utilization of secondary group IDs.
      A primary authorization ID may be associated to secondary
      group IDs that are granted the necessary privileges, and
      these secondary group IDs are recognized relative to
      non DB2 for z/OS remote client application environments.
      The goal is for DB2 for z/OS server systems to provide
      consistent authorization behavior for all remote DRDA client
      application environments, DB2 for z/OS and non DB2 for z/OS,
      yet the new authorization environment does not consider
      secondary group IDs for remote DB2 for z/OS DRDA client
      applications.
    

Problem conclusion

Temporary fix

Comments

  • DB2 for z/OS server processing, relative to remote (via DRDA)
    DB2 for z/OS client applications only, is changed to provide
    additional enhancements for the benefit of moving to an
    environment that provides consistent authorization behavior
    with respect to remote non DB2 for z/OS client applications.
    o Users need a more flexible environment.
      In DB2 for z/OS V8 and V9, the DSN6FAC PRIVATE_PROTOCOL
      parameter is extended to allow for a new AUTH keyword.
      Specifying AUTH indicates that Private Protocol is disabled
      (like NO) yet still allows the old authorization behavior for
      the benefit of remote DB2 for z/OS DRDA client applications
      that may still rely on it.
      In DB2 10 for z/OS, the PRIVATE_PROTOCOL parameter is being
      added to the DSN6FAC configuration macro. Specifying AUTH
      still allows the old authorization behavior for the benefit
      of remote DB2 for z/OS DRDA client applications that may
      still rely on it. A specification of NO is the default.
      Specifying YES is not supported in DB2 10 for z/OS.
      Note:
        The default DSN6FAC PRIVATE_PROTOCOL specification in
        DB2 for z/OS V8 and V9 is YES (which allows old
        authorization behavior), but since actual support of
        Private Protocol has been eliminated in DB2 10 for z/OS,
        the default behavior in DB2 10 for z/OS is NO (which
        prevents old authorization behavior).
        All DB2 z/OS V8 and V9 users that are migrating to DB2 10
        for z/OS with a DSN6FAC PRIVATE_PROTOCOL specification of
        YES (the default), or AUTH (with PM37300 applied), should
        be aware of this release incompatibility. It may be
        necessary for users to install PM37300 to their target
        DB2 10 for z/OS environment and insure that DSN6FAC
        PRIVATE_PROTOCOL=AUTH is specified.
      Note:
        DB2 10 for z/OS installation support for the
        PRIVATE_PROTOCOL parameter is provided in APAR PM38417.
        This APAR also provides installation support for the new
        PRIVATE_PROTOCOL AUTH keyword in DB2 for z/OS V8 and V9.
    o Utilization of secondary group IDs.
      When the DB2 for z/OS server subsystem is configured to allow
      the new authorization behavior for remote DB2 for z/OS DRDA
      client applications, secondary group IDs will now be utilized
      in the authorization scheme and the Plan Name associated with
      the remote DB2 for z/OS DRDA client applications will now be
      reported as DISTSERV.
    

APAR Information

  • APAR number

    PM37300

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    A10

  • Status

    CLOSED UR1

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2011-04-18

  • Closed date

    2011-05-12

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

    UK67639 UK67640 UK67641

Modules/Macros

  • DSNDFAC  DSNLTACC DSN6FAC
    

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • RA10 PSY UK67639

       UP11/05/24 P F105

  • R810 PSY UK67640

       UP11/05/24 P F105

  • R910 PSY UK67641

       UP11/05/24 P F105

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":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"10.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":"10.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
15 June 2011