How does authorization checking work in RC/Edit within RC/Update edit table processing

Products

RC/Update for DB2 for z/OS Database Management for DB2 for z/OS - Administration Suite

Issue/Introduction

In RC/Update for Db2 for z/OS (RCU) the AUTHORIZATION CHECKING is done via Db2 or internally
with either the RC/Update Profile or hlq.CDBAPARM(DEFAULTS) UAUTH setting. How does this work?

Environment

Release: R19, R20
Component: RC/Update for Db2 for z/OS

Resolution

When RC/Update must check that an authid has the appropriate authorities to carry out an operation on table data it can
hand this task directly to DB2 at the time when the operation must be carried out or it can predetermine the
primary authids' authority to do so internally.

PERFORM AUTHORIZATION CHECKING in DB2

In general if a primary Authid does not have the required DB2 authority for an action, DB2 does authority checking by establishing
whether a primary Authid belongs to a secondary Authid group. This determines whether the appropriate authorities exist on the
object via the group authority. The checking is done via the DB2 security exit.

PERFORM AUTHORIZATION CHECKING in RC/Update

The PERFORM AUTHORIZATION CHECKING flag establishes whether RC/Update will directly handle the task of checking
the Authids' authority over a table or a view during a data edit session.

Perform Authorization Checking can be implemented via the RC/Update User Profile or via hlq.CDBAPARM(DEFAULTS).
When implemented through hlq.CDBAPARM(DEFAULTS) it applies to all users. When implemented through the
RC/Update User Profile it applies to a single user.

PERFORM AUTHORIZATION CHECKING implemented via RC/Update User PROFILE

The "Perform authorization checking" flag can be found in the RC/Update Profile, RC/Edit Profile Variables. It can be set to "Y" or "N" and only applies to that single user.

RC/UPDATE - RC/EDIT

Perform authorization checking before entering (Y) or (N)

PERFORM AUTHORIZATION CHECKING implemented via hlq.CDBAPARM(DEFAULTS)

The PERFORM AUTHORIZATION CHECKING flag can be found in the hlq.CDBAPARM(DEFAULTS) member in section
"RC/EDIT-BROWSE DEFAULT VALUES" and is called UAUTH. To enable the use of the DEFAULTS member for all users,
the hlq.CDBAPARM (SETUPxx) member must have DEFAULTS (YES) specified.

UAUTH (N) or (Y) Y - PERFORM CHECKING, N - SKIP CHECKING

The RC/Update RC/Edit User Profile overrides the setting for the UAUTH parm in hlq.CDBAPARMS(DEFAULTS). However, if
the Defaults Administrator sets the Read Only(R-O) flag for UAUTH to "Y", this prevents the user from changing the
"Perform authorization checking" parm in the RC/Edit profile section of their RC/Update User profile.

Authorization Checking Flag set to "N"

When the Authorization Checking Flag is "N" the task of checking authorization is handed to DB2 directly. It does not do
any authorization checking before the data retrieval. It therefore does not protect any columns but rather allows DB2 to
determine if the select, update, insert or delete statements may be performed at execution time. Note that with this option
you could complete the edit session but not be allowed to write the changes if you do not have the required authority.

Authorization Checking Flag set to "Y"

When the Authorization Checking Flag is set to "Y", RC/Update will check the authorization before it retrieves any data
for the table or view. It tries to establish the authority of the Authid to perform actions on the data in the object being accessed.
This allows RC/Update to protect any columns that the Authid does not have authority to update.

Currently the following processing occurs:

The Primary Authid is checked to determine if it has SYSADM authority.
If not then PUBLIC* is checked for SYSADM authority.
If not then each Secondary ID is checked for SYSADM authority. This process is repeated to determine DBADM authority if none of the IDs have SYSADM authority.
If none of the IDs have DBADM authority then each ID is then checked to determine if they have table level authority (Select, Update, etc.).
If none of the IDs have authority to perform the desired action then the RU359E message is displayed.

Secondary Authid Checking process when the Authorization Checking Flag is "Y"

There is a limit of 255 secondary IDs which can be processed for Secondary ID Authid checks in RC/Update. RC/Update calls
Database Management Solutions for DB2 for z/OS Common services to obtain the secondary IDs that are associated with
a particular Primary Authid. Note also there is a possibility that the list of groups attached to an Authid could be greater than the
limit if some of the IDs are connected to other groups. This means that message RU359E could be received if there are more
than 255 ids to check and the Secondary Authid that has the required privilege is not one of the 255 ids in the list.
An extra PUBLIC ID is processed which everyone is part of.

Authority Checking for VIEW's when the Authorization Checking flag is "Y"

When a view is used as the object of SQL DML operations RC/Update will SQL PREPARE the statement in order to establish
the Authids' authority to do these operations by examining the PREPARE result. The Authority over VIEWS's is more difficult
to establish than base tables due to the possible complexity of VIEWS with multiple base tables. The SQL PREPARE must
return a positive result. Many base tables could be involved in an updateable view.

Access to the DB2 Catalog

Authority to SELECT DB2 catalog tables must be GRANTed where the object resides. This is required and must be granted to either
the primary Authid, secondary authorization ID or in the case of remote locations "PUBLIC AT ALL LOCATIONS" in the remote DB2.
The SQL DML statements issued by RC/Update on tables and views are dynamic SQL and as such, authority is established
when these are prepared during dynamic execution.

Messages to the User

If Db2 is doing the authorization checking it informs the user of any authorization problems when the operation is attempted.
If RC/Update requires knowledge of your authority before the operation is attempted then it can check your authority as previously described above.
In either case if the appropriate authority can't be found then some of the error messages below may be seen:

RC/Update error message:

RCU51 SQL-551 WHEN UPDATING TABLE W/ COLUMN AUTHORITY

RU359E YOU LACK AUTHORITY FOR HIGHLIGHTED LINE COMMANDS.

DB2 Error messages that may be seen include: