IBM Data and AI Ideas Portal for Customers
This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
IBM Employees should enter Ideas at https://ideas.ibm.com
Thank you for submitting this Db2 for z/OS Idea.
After giving the request a comprehensive review, we have determined that we cannot include it as a candidate in an upcoming deliverable because it is not consistent with the product direction for future deliverables. As a consequence we will not be implementing this Idea.
We appreciate your input to the Db2 for z/OS development team. We also hope that you will continue to submit ideas for improvements as customer feedback is a key component to shaping the future direction of Db2 for z/OS.
Sincerely,
Db2 for z/OS Team
IBM,
Thanks for your consideration. There are a couple of reasons why the INSTALL SYSOPR approach is not, in my opinion, ideal:
First of all, the installation privileges, INSTALL SYSOPR and INSTALL SYSADM, bypass the SAF, since they are coded into the ZPARM module. This means that we have no ability to audit anything done under INSTALL SYSOPR privilege within our SAF environment. This presents a security risk.
Second, the use of INSTALL SYSOPR requires some custom configuration to the security environment, making the procedure esoteric and cryptic, rather than straightforward and standard. For example, it requires the creation of the ID "SYSINSTL" in our security environment to be creator/definer of many of the system routines defined by DSNTIJRT. Our shop does not generally support the use of secondary IDs in our mainframe environment, particularly switching into secondary IDs.
Third, INSTALL SYSOPR grants privileges beyond the scope of simply managing SYSTOOLS/SYSFUN schemas. The granularity and specificity of Db2 permissions is one of its major advantages, and I have long advocated the position that administrative authorities should be avoided wherever possible and permissions should be granted explicitly, following the guideline of "least privilege". According to the Db2 12 "Managing Security" guide, INSTALL SYSOPR provides some pretty broad authorities, including the ability to issue virtually any Db2 Command, as well as the ability to use any ID as a "BIND AGENT". The BIND AGENT authority particularly has a broad capacity for abuse, for someone who understands it well enough.
DSNTIJRT/actual installation is not the only time when one would want to change the operating environment of a SYSTOOLS function. Recently, we had a user request Db2 JSON functionality. The BSON2JSON and JSON2BSON routines (SYSTOOLS schema) were defined to DSNWLM_NOT_ENABLED. We did not want to run the full DSNTIJRT again, so I attempted to perform an ALTER and point the functions to a different WLM APPLENV. Doing so generated a security violation and resulted in suspension.
To be honest, I believed that the Install SYSOPR/SYSINSTL solution was intended to provide customers with a temporary work-around until this issue could be given a more permanent resolution. I am not fully understanding why every other schema, including some system schemas like SYSIBM, allow for the customer to define the Schema, database, tables, packages, plans, etc as explicit resources to be granularly controlled, while SYSFUN and SYSTOOLS require the grant of an administrative privilege that the customer may not desire to use and that carries permissions beyond the scope of these schemas.
Although this restriction seems well-meaning, it makes broad assumptions about how customers manage their mainframe security environments, as well as how they manage the roles and responsibilities related to Db2. In that light, it seems arbitrary and capricious.
I am not asking for any "special" operation for these schemas...rather, I am asking that the "special" operation be removed, and the SYSFUN/SYSTOOLS schemas be able to be granted, revoked, and managed as every other schema in Db2.
I hope this clarifies my position on this RFE. If you have any further questions, let me know.
Thanks
-Mark
Hi Mark, This requirement was originally submitted as RFE 121868. In that RFE we had stated DSNTIJRT can be run with INSTALL SYSOPER privilege. Can you please explain why this is not a reasonable alternative?
Thank you.