Authorization checking for executing packages
If PKLIST is specified in the BIND and REBIND options and the location.collection is an asterisk (*), Db2 defers the package authorization check until run time. Make sure that you use a specific location name or omit this part of the identifier if you do not want the package authorization check deferred until run time.
If
you execute the packages remotely, make sure that the privileges required
for a remote bind (BIND PACKAGE location.collection)
are granted at the server location. The ID that owns the package must
have all of the privileges that are required to run the package at
the server, and BINDADD1 and CREATE IN privileges at the server.
Exceptions:
- For a BIND COPY operation, the owner must have the COPY privilege at the local Db2 site or subsystem, where the package that is being copied resides.
- If the creator of the package is not the owner, the creator must have SYSCTRL authority or higher, or must have been granted the BINDAGENT privilege by the owner. That authority or privilege is granted at the local Db2.
Binding a plan with a package list (BIND PLAN PKLIST) is done at the local Db2, and bind privileges must be held there. Authorization to execute a package at a remote location is checked at execution time, as follows:
- If the server is a Db2 for z/OS® subsystem:
- If the subsystem parameter PRIVATE_PROTOCOL is set to NO, the authorization ID of the process (primary ID or any secondary ID) must have the EXECUTE privilege for the package at the Db2 server.
- If subsystem parameter PRIVATE_PROTOCOL is set to AUTH, the owner of the plan at the Db2 requester must have the EXECUTE privilege on the package at the Db2 server.
- If the server is not Db2 for z/OS,
the primary authorization ID must have whatever privileges are needed.
Check that product's documentation.
