DRDA server access control exit programs

 

A security feature of the Distributed Relational Database Architecture™ (DRDA^®) server, for use with both Advanced Program-to-Program Communication (APPC) and TCP/IP, extends the use of the DDMACC parameter of the Change Network Attributes (CHGNETA) command to DRDA.

The parameter previously applied only to DDM file I/O access. The DRDA usage of the function is limited to connection requests, however, and not to requests for data after the connection is made.

If you do not choose to use this security function, you normally do not need to do anything. The only exception is if you are currently using a DDM exit program that is coded to reject operations if an unknown function code is received, and you are also using DRDA to access data on that system. In this case, change your exit program so that a '1' is returned to allow DRDA access if the function code is 'SQLCNN '.

To use the exit program for blocking or filtering DRDA connections, create a new DRDA exit program, or change an existing one.

If your system is configured with multiple databases (ASP groups), the exit program must reside in a library in the system database (on an auxiliary storage pool in the range 1-32).

You can find general instructions for creating a DRDA exit program in the Distributed data management topic.

This security feature adds a DRDA function code to the list of request functions that can be input to the program in the input parameter structure. The function code, named 'SQLCNN ' (SQL connect request), indicates that a DRDA connection request is being processed (see the FUNC parameter in Example: DRDA server access control exit program). The APP (application) input parameter is set to '*DRDA ' instead of '*DDM ' for DRDA connection request calls.

When you code exit programs for DRDA, the following fields in the parameter structure might be useful:

• The USER field allows the program to allow or deny DRDA access based on the user profile ID.

• The RDBNAME field contains the name of the RDB to which the user wants to connect. This can be the system database or a user database (ASP group). This field can be useful if you want to deny access to one or more databases in an environment where multiple databases are configured.

• The SRVNAME parameter in the topic Example: DRDA server access control exit program might or might not be set by the caller of the exit program. If it is set, it indicates the name of the client system. If it is not set, it has the value *N. It is always set when the DRDA application requester is a System i™ product.

• The TYPDEFN parameter gives additional information about the type of client that is connecting. For an IBM^® mainframe, TYPEDEFN is QTDSQL370. For a System i product, it is QTDSQL400. For an Intel^® PC, it is QTDSQLX86. For an RS/6000^® client, it is QTDSQLASC.

• The PRDID (product ID) parameter identifies the product that is attempting to connect, along with the product's release level. Here is a partial list of the first three characters of these codes (You should verify the non-IBM codes before you use them in an exit program):

  QSQ

  IBM DB2 Universal Database™ for iSeries™

  DSN

  IBM DB2 Universal Database for z/OS^®

  SQL

  IBM DB2^® for Linux^®, UNIX^®, and Windows^® (formerly called DDCS)

  ARI

  IBM DB2 Universal Database for VSE & VM

  GTW

  Oracle Corporation products

  GVW

  Grandview DB/DC Systems products

  XDB

  XDB Systems products

  IFX

  Informix^® Software products

  SIG

  StarQuest products

  STH

  FileTek products

  JCC

  IBM DB2 Universal Driver for SQLJ and JDBC

  The rest of the field is structured as vvrrm, where vv is version, rr is release, and m is modification level.

If the exit program returns a RTNCODE value of 0, and the connection request came from an i5/OS^® client, then the message indicating the connection failure to the user will be SQ30060, User is not authorized to relational database ... In general, the response to a denial of access by the exit program is the DRDA RDBATHRM reply message, which indicates that the user is not authorized to the relational database. Different client platforms might report the error differently to the user.

 

Restrictions:

• If a function check occurs in the user exit program, the program returns the same reply message, and the connection attempt will fail. The exit program must not do any committable updates to DB2 UDB for iSeries, or unpredictable results might occur.

• You should not use exit programs to attempt to access a file that was opened in a prior call of the prestart server job.

• Prior to V5R2, a further restriction resulted when the prestart jobs used with the TCP/IP server were recycled for subsequent use. Some cleanup is done to prepare the job for its next use. Part of this processing involves using the Reclaim Activation Group (RCLACTGRP) command with the ACTGRP parameter with value of *ELIGIBLE. As a result, attempts to use any residual linkages in the prestart server job to activation groups destroyed by the RCLACTGRP can result in MCH3402 exceptions (where the program tried to refer to all or part of an object that no longer exists). One circumvention to this restriction is to set the MAXUSE value for the QRWTSRVR prestart jobs to 1 as follows: CHGPJE SBSD(QSYSWRK) PGM(QRWTSRVR) MAXUSE(1).

• Example: DRDA server access control exit program
  This exit program shows an example of a PL/I exit program that allows all DRDA operations and all DRDA connections except when the user ID is ALIEN.

 

Parent topic:

Security

 

Related concepts

Object-related security for DRDA
Distributed data management

 

Related reference

Reclaim Activation Group (RCLACTGRP) command
Change Network Attributes (CHGNETA) command