RE: v6r1 ptfs chg security requiremnt setting QAQQINI lib

Could you write an exit program for exit point QIBM_QZDA_SQL2 (an exit point for QZDASOINIT) that...

1. Swaps to a user profile that can perform the necessary change.
2. Makes the change.
3. Swap back to the calling user profile.

?

Gary Monnier


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, May 08, 2012 12:12 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: v6r1 ptfs chg security requiremnt setting QAQQINI lib

On 08 May 2012 07:08, J Franz wrote:

In some of the recent ptfs, IBM has added an error msg in a QZDASOINIT
job (pc client, odbc) where setting the QAQQINI lib in the dsn caused
a CPF9898 error that allows process to run, but QAQQINI lib not
changed and used default.

I understand why IBM is adding this, and Scott Forstie wrote a great
article:
http://www-03.ibm.com/systems/resources/systems_i_db2_navigator_securi
ty_controls.pdf

but short of giving user *jobctl auth (not going to happen) or the
QIBM_DB_SQLADM function usage for each user (lot's of users and
changes often), it seems cannot easily point a job to a diff QAQQINI.

We have lot's of client code written in diff tools, not easily
changed, and need to force certain work thru CQE (it still works
there..), while others need SQE for performance.

Is there an alternative method to point to various QAQQINI's from
various apps? (btw-i'm not the pc client developer..)

There is an exit program for the client requests, and there are also SQL "client" special registers which could presumably be accessed to determine an appropriate setting. I do not recall if the connection string [e.g. for keyword QAQQINILIB or QAQQINILibrary] is available to the exit program interface, which I suppose would be better to allow a transparent transition; i.e. to allow whatever is the security concern to become the onus of the exit program implementing the same effect as what was done by the OS prior to any [PTF] changes.

Presumably a stored procedure call, a program using adopted authority, could issue a CHGQRYA. The program implementing the stored procedure could be a CLP that accepts an input parameter for the QRYOPTLIB. Then instead of the connection string, the client application could insert a CALL to that procedure.?

Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.