PM37300: CHANGE AUTHORIZATION CHECKS TO RECOGNIZE SECONDARY IDS 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 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 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.