A fix is available
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":"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":"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